Snow Leopard and Spaces bug

I'd say that's more a bug in Spaces than in Sparkle.

The reason of course is that Sparkle first moves aside the old version, than copies in the new version, and if everything succeeds removes the old version. This is the correct thing to do and should not be changed. Apparently the Spaces prefs follow the app by alias reference and loose it in the last step. They should look at the app name or probably better the bundle identifier.

That may be true. But OS X is what it is, there were bugs in Spaces that
persisted from Leopard's release thru Snow Leopard's. If at all possible
Sparkle should attempt a work around. It just makes updating smoother. (at
least for those of us who use Spaces).

This is definitely a problem in Spaces, but maybe there's something we can do to fix it up: a plist somewhere or something. Obviously, the update would proceed if this failed.

I'll investigate more down the road.

The thing is that I don't see a way to fix this without removing more important features. What I tried to say is that changing the way Sparkle replaces the app in order to fix this bug would be a very bad idea, you don't fix a bug by introducing a more severe one. Of course if there were a way to avoid this without these negative side effects that should be looked into. I just don't see it. And Andy, if you're talking about patching a system pref plist: really don't go there!

Is someway (either by default, or by an extra/optional bit of work in
implementation by an app's developer) that an application could
poll NSWindowCollectionBehavior and see how its preference is set before
update, save that setting in a plist, and then re-set that preference after
update thru NSWindowCollectionBehavior?

The system prefs are not public (a few partial exceptions that are unrelated.)

I know System Prefs aren't public. But a developer can have their
application to poll its NSWindowCollectionBehavior, which is its Spaces
preference setting (I'm just learning cocoa, but it looks that way).

So my point is that when a developer is implementing Sparkle, ideally there
would be a way for them to set up Sparkle's update behavior to check
NSWindowCollectionBehavior,
log it somewhere, and then update, relaunch, and re-set
NSWindowCollectionBehavior
using the logged info.

There is nothing like this. Individual NSWindow objects have an NSWindowCollectionBehavior setting, but that one has nothing to do with the system pref. I repeat, there is NO public way to get (and certainly not set) this behavior of the app.

BTW, I cannot reproduce your problem. I can also say that Apple does save this setting based on the bundle ID, not an alias or something (it's in the workspaces-app-bindings in the com.apple.dock domain). This makes it very unlikely that this problem as you describe it can even occur. I suspect that there's something else going on for you.