Thanks for the feedback, and sorry for the frustration.
Here are some things we’re working on to make this better.
First, proper version pinning for imports (and requires). This will allow notebooks to capture exact versions of imported notebooks and their transitive dependencies, similar to how yarn captures exact versions in a yarn.lock file. This ensures that notebooks keep working into the future: imported code will never change. Internally it will work similar to how you describe: imported notebooks are referenced by id@version (e.g., 09403b146bada149@257 for the current version of @d3/bar-chart).
Second, editable URLs. We’d like to show you what the URL will be before you publish, and give you an opportunity to change it if necessary. And internally we already support changing the URL of a notebook with redirects (e.g., @mbostock/d3-bar-chart redirects to @d3/bar-chart), so we’ll allow you to change the URL after publish, too. (If you want to change the URL of a published notebook in the meantime, please email support. We’d be happy to help!) We’re also thinking about allowing human-readable URLs for private notebooks and for shared notebooks that aren’t listed publicly or discoverable via search.
That said, we’re not planning on letting you re-assign a URL (slug) to a different notebook. Even with version pinning, I think it would be confusing to have a different association between the human-readable name of a notebook and its identity/history (e.g., @d3/bar-chart@256 meaning something completely different). The human-readable name matters too, and it’s easier to reason about a sequential history than large hexadecimal identifiers (or content hashes). But as an author you can always completely overwrite the content of a notebook as a new version, or trash the old notebook and publish a new notebook at a different URL (slug).