Jim was looking at this on Windows

Is the persistence issue on Windows only or also affects Mac?

Windows and Mac.

The SafariDriver is still extension based, but as of revision dcb0f976cf54, there is
a prebuilt copy of this extension checked into the repo and bundled with java client.
 This extension will be automatically installed when creating a new SafariDriver instance
and uninstalled on quit() or JVM shutdown.  Safari's previous extension settings will
be restored when the extension is uninstalled.

You can still use a custom version of the extension with the webdriver.safari.driver
system property, or you can skip installing the extension altogether with -Dwebdriver.safari.noinstall=true
(e.g. if you've preinstalled a copy of the extension).

For all intents and purposes, this is now fixed.

A few questions for clarification:

* So to confirm, this will now work with SafariDriver() on Java client and when requesting
for Safari with RemoteWebDriver for any language binding/client? So this is bundled
into the standalone server JAR as well? Or just the Java client JAR?

* If specifying custom extension, does it use a copy of the specified extension (like
specifying Firefox profiles) or the exact file? Because Safari browser will always
delete the extension installer file after installation. So if it uses exact file, should
make a note of that for users so they won't be confused when at next run, the specified
extension doesn't exist.

* Is this going to be (automatically) in place going forward for each new release or
just for this current/next release? Where a prebuilt copy of extension gets checked
into repo (or auto-built from source) then bundled into JARs for every release as part
of build/release process. By the way, which release is this currently fixed for 2.28
or next release (or trunk build), I'm assuming the latter?

* I thought the Selenium team had issue getting Apple certificate for the project to
distribute a binary installer. Did that get resolved, or did the team decide to just
bypass that for now and do this unofficially with one of the developer's certificate?

1. When you request safari through the java standalone server, it ultimately invokes
"new SafariDriver()", so yes, you will get the same benefit that way.

2. All of your existing extensions will be backed up to a temporary folder (and restored
when you call webdriver.quit() or the JVM exits).  The prebuilt extension is extracted
from the jar and copied into Safari's extension folder, so you can reuse it.

3. The prebuilt will have to be manually generated and checked into the repo, but it
will be automatically included in all future releases.

4. I used my dev certificate.

I think one question wasn't phrased correctly, so let me try again: 

if we specify a custom SafariDriver extension instead of the prebuilt one in the JAR,
will the process make a copy of the specified custom extension file and install using
the copy or will it install using the specified custom extension file itself as the
source? 

It copies it over. Being able to use your own extension specified through a system property
was actually implemented a while ago.  Try it out with 2.29

Also just wanted to confirm, this new functionality does not affect Grid2 operation.
Start Selenium node (registering for Safari) as usual, and now it will auto-install
& uninstall the extension at every test, and not need to preinstall the extension as
before.

Oops, comment 10 was meant to be a question, FYI. Sent too soon.

When you create a new session with the java server, it ultimately ends up using the
browser-specific class (e.g. FirefoxDriver, SafariDriver, etc.).  So yes, it should
use the pre-packaged extension for Grid2.