A Correct Way to Organize a Sandbox
While there may be other correct ways to organize a multi-page sandbox, this is the system that I use, and that I believe ought to be adopted as the official sandbox organization system.
Each user and each multi-user project gets a unique page prefix. In the case of a user, that prefix should be their username; for a team, use the team name or something. Each prefix should have a single sandbox root page, located at http://scpsandbox2.wikidot.com/my-prefix, and this page should contain a [[module PageTree]]. Then, each draft or other document should be created located at http://scpsandbox2.wikidot.com/my-prefix-my-draft-name. Each sandbox page should then be parented to the sandbox hub - this is done by selecting +more options>parent at the bottom of the page, and entering the name of the sandbox hub. And then you are done. This will, in addition to adding breadcrumbs navigation to the page, automatically add a link to the new sandbox page from the hub page.
Possible Concerns
This system addresses all of the reasons I have ever heard or thought of for why one might want to limit the number of sandboxes:
Namespace Conflicts
Using the sandbox hub prefix, it is not possible for personal sandboxes to conflict, wikidot usernames are unique. Meaning, that there is no reason for anyone other than use Joe to want to create a sandbox page with the prefix 'joe'. In the case of team hubs this is not completely guaranteed, however once one team creates the hub, that very clearly marks that prefix as in-use, and anyone looking to create a new hub will just need to pick a new hub prefix.
Storage Space
There isn't a limit on the number of pages that can be created.
"Clutter"
This is the polar opposite of clutter - this is an extremely-well structured system that, if used correctly, guarantees that no pages will ever be orphaned or lost. Additionally, having everything parented to the root makes it very easy to manage the sandbox - for instance deleting the root, or moving it to a different category, will automatically delete or move every other page in the sandbox.
Abuse
Sure this can be abused, just like any other system. A user could deface someone else's sandbox under the current system too. However, by using multiple pages, it becomes much easier to revert any vandalism (due to having separate edit histories for each page), and potentially could reduce the total scope, since they would need to individually vandalize each sandbox page.
This is Too Complicated
This may be a valid concern, but in reality the per-page complexity actually is significantly less. Adding a new tab to a tabview, including titling it and getting all the code where it need to go, is not a trivial operation, and is in fact significantly more complicated than setting a page's parent and changing a page title.
New Users
Most new users are going to abuse the system and ignore everything anyway. The fact they are making a sandbox at all means they didn't ignore that piece of advice, and it should be simple to add a guide on how to use the sandbox as well. The few users who do ignore everything but still end up on the sandbox site will still create disorganized sandboxes anyway, and there is nothing that can be done about it. This is not meant to address that bottom 30%, and there is very little that will. However, this system does not require that every sandbox user use it for it to work. I have successfully used this system, by myself, for nearly as long as I have had a sandbox at all, and it works excellently.
Teaching new users to use a system like this from the start is significantly easier than teaching it to them after they have already gotten used to tabs. Will they create lots and lots of extra page that they don't need? Yes of course. But it doesn't matter! All of those pages will be isolated in their own sandbox namespace, and if it bothers you, you don't have to look at it!
If needed it would not be too hard to add a sandbox creation wizard to automatically initialize a new user's sandbox hub, and even add a button to it to automatically create subpages and parent them to the hub. I've read the wikidot docs on this feature, and this discussion gives detailed info about how to do something that is very close.
Advantages of This System over using Tabs
Editing
Now when one edits a page, you don't need to scroll past a half-dozen other drafts to find the one you want to fix. You just open it up and you are already right there. Plus, no need to use a tabview module or anything else that can sometimes cause some wikidot code to render differently, ensuring that when you finally post it to the site, it will look exactly the same as it did in the sandbox.
Links
Using this system, one can now link directly to a draft. No more 'post the link and tell them which tab to go to' nonsense; that is too much user friction, especially when you can just give them a link that takes them right there.
Organization
Using this system, the pages become organized by default. Additionally, management operations like deleting a sandbox or moving it become much simpler, requiring only one action.
Version Control
By putting different drafts on different pages, you separate the page histories from each other. Before, one needed to search through several pages of history to find a revision containing the older version you want, and then you needed to copy that out of the history and paste it into a new version, since if you just hit the 'revert' button it would also revert all of the other drafts back to where they were then.
With separate pages, the 'revert' functionality actually becomes legitimately useful, since it will only revert the draft in question, without erasing all the other changes you have made to all your other drafts.
