Yeah, I'll probably change it from "Sphere 2.0" to just Sphere.  I was leery of putting a space there myself, but having a camelcase directory inside My Documents looks just as odd to a Windows user as "Sphere 2.0" does to a Linux user.  But yes, I agree that we shouldn't be creating paths with spaces under *nix.

In any case the standard doesn't need to specify the exact path, the only requirements for the "user data" directory from an engine implementor's point of view is: 1. It must be writable and 2. It must be user-local whenever possible.  Whether that means the user's documents folder or some other "app data" location doesn't matter as long as the above requirements are met.

That's my take on it anyway.

I started work on a specification for SphereFS, GitHub doesn't seem to have a done a good job with the markdown though (or I screwed up the layout, that's possible too...):
https://github.com/sphere-group/pegasus/blob/master/design/SphereFS.md

I've never written a specification before, it's kind of fun being able to throw around words like "shall" and "must" with reckless abandon.

Nooo why are you going with ~/ an #/ now

What can I say, I prefer the single-character aliases.  I added more to the spec, laying out requirements for writability/non-writability for the different locations.  For example I added a requirement that the engine should not allow write access to the game directory unless it declares support for the Sphere 1.x API.

That's what I did in TurboSphere. #/ meant the system directory.