Background
The URL of a deck page is formed in such a way that it includes the deck revision, the slide id and revision if a slide is selected, as well as the path to the slide in question. There is the notion of a Deck URL that only includes the deck id (and not the revision), but once a visitor navigates through the deck slides, the URL changes to this "canonical" form. Moreover, when a user edits a slide and saves it, the URL for the slide will include the new revision. We currently support links to slides that only include the deck id and slide id and no revisions, but it's not clear where they are generated by the system (I've seen them in recent decks section of the home page), and once a visitor starts navigating the page they are replaced with the non-permanent, revision- and path-including URLs.
The way most people share links of pages is via the URL on the address bar. Constantly changing URLs that include implementation details like revision IDs create issues for people sharing those links.
There is of course a use case for URLs pointing to specific revisions, but those should result in pages where it is more clear in the UI that they don't relate to the currently active revision. I would expect when I edit a slide and save it for the URL to be the canonical form without the revision. If I bookmark the slide page and revisit at a later time, I expect to see the active revision. If I want to explicitly bookmark the revision-specific version, I should be able to use a dedicated revision permalink control or something like that.
Moreover, friendly and stable URLs are a major component of any serious SEO effort. People will include slidewiki links with URLs copied from their address bar in their pages, no matter how good a UX for permalink generation we may devise. In the old slidewiki the URLs also included the Deck title (slug form) which is also a good SEO practice we should apply in this version as well.
Another related issue is Deck visibility and URL availability. Currently, if a user creates creates and adds a new subdeck to a deck, that subdeck also has its own URL as if it was a root deck. Because the use cases for using subdecks are not restricted in any way, that user may not wish for this subdeck to be available on its own, because it would be out of context. Another use case where a user might wish for a deck they own not to be accessible in the web site is when they would like to delete a deck or when they would like to report a deck for license violation etc. This of course relates to the discussion here: Delete/Remove option for decks.
Deck visibility, specifically of sub-decks, comes in another an issue as well: search results. Currently if a term is matched in a particular slide, the search service points to the deck that is the immediate parent of that deck. Users can still navigate to any parents of the deck using the Usage tab, but if that parent is only one (because the deck was created strictly as a sub-deck of the parent), it would be better for the visitor to access the slide in its proper context. If the deck author wishes for a subdeck to be available out-of-context of the parent deck, they should be able to decide to mark it as such explicitly.
Action items