P.S. @djdolphin: Never mind, the problem I noticed is that the path to the library is now .../snap/libraries rather than .../snapsource/libraries. I have a fix for that.
But a more serious problem that I don't know how to fix is that if you turn on bignums and then you load a different project into the same Snap! instance (or start a new one with ^N), bignums are still turned on even though the library blocks aren't available in the palette. That must have been true all along!
I was just about to comment on the URL thing 
Yes, I believe the project switching problem has been there all along. I don't think there's a good fix for that besides overriding more Snap! internals (bad idea) or telling users to disable bignums before switching projects.
Moved to new thread to avoid hijacking the old one.
When I invented the Eisenbergification library, Jens added a flag variable ide.savingPreferences that I set to False whenever changing any preference that should be per-user rather than per-project, so Snap! undoes the changes on exit from the project.
Maybe we need something more general instead of a special hack for Eisenbergification -- a WHEN LEAVING PROJECT hat block or something like that.
No. You need to do bignums right, not cut corners by overloading functions like you do.
Doing it right would be building it into Snap! and having all arithmetic use it. I'm all for that!
What is it you mean by "doing it right"?
Doing bignums right means not overloading Snap and certainly not overloading JS. Instead you offer an alternative set of bignum arithmetic reporters. Yes, it doesn't do all that bignums currently does, but it also doesn't misbehave the way bignums currently misbehaves.
Hmm. If we do it right, there won't be any question of overloading vs. alternative reporters.
P.S. Really, if we're going to offer two sets of arithmetic operators, one mathematically correct and the other not mathematically correct, I say it's the latter that you should have to ask for specially.
Sure. When JS does bignums all will be fine. In the meantime we have to ask for it unless we overload JS. I think overloading JS is a very problematic idea, and I'm quite certain that I feel overloading Snap primitives is a quite unfriendly act.
When JS does bignums that doesn't help at all unless they also do exact rationals and complex numbers. Pretend I'm a user and I need the full Scheme tower for my math class.