Should we make the ephemeral aspect of Playgrounds permanent?

[juliendorra]

(yes this question sound like an oxymoron, but in fact is not :-)

It actually emerged here: #99 (comment) and here: #99 (comment)

Pros:

1. It makes difficult for a group to monopolize certain Playground names. There is no fixed territories. Your space is your space only if you cultivate it. If you abandon it, it goes back to the commons.
2. Playgrounds are leveled afresh so there's never playgrounds full of crufty old code or playgrounds in disarray.
3. It keeps with the live code idea and discourage the creation of static "pieces of art"
4. It's a different way to see programming, not as building something forever but more like creating a sandcastle or a mandala. It embraces impermanence.
5. It is truly behaving like a sandbox in a park or fresh sand at the beach: if you leave your creation unattended, it disappears. And we all love sandboxes and beaches, don't we?
6. A paysage playground is like a meeting place, not a document. So it's up to the people meeting there to do something. They can't be passive.

Cons:

7. It makes difficult to resume a collective coding session. We would have to save all the code one by one and then paste them back when coming back.
8. It makes a playground's URL shared on social media only good for showing code for a day, maybe a day and half. This makes sharing a playground URL on a blog or any long lived medium only useful as a meeting place, not to show some code.
9. It goes against the principle of asynchronous sharing upon which the web is built.
10. A paysage playground is not a document, and we can't use them to store and show creative coding creations.

Cons 7 could be mitigated by a [download Playground] as JSON features, probably in /list.
A new playground could then be regenerated from a JSON local file or URL (gist…) as in openjscad.org with a [generate playground from JSON] action in /list.

Do you see other Pros and Cons to the ephemeral nature of Paysage playgrounds?