I don't want to encourage further Flow development, but if you're going to do this anyway, I guess I may as well comment.
All of the proposals basically amount to expanding the format with arbitrary redundant text. You're basically just changing [[Topic:T47jqwe15hsw3ai0]] to [[Topic:T47jqwe15hsw3ai0|Readable Name]]. Oh look! It already works! Topic:T47jqwe15hsw3ai0 becomes Readable Name! The proposals here don't do much to improve on that.
Instead of a big garbage string UUID, how about this:
- If Pagename(separator)Topic is currently unique, then just use it! This is doable, even if you have to do a database lookup on the readable title to obtain your internal UUID.
- If Pagename(separator)Topic is already in use, append a micro unique ID like this: Pagename(separator)Topic(separator)1. Again this is doable, even if you have to do a database lookup on that URL to obtain your internal UUID. There would have to be 38(?) identically named topics on the page before you needed a two character micro ID. There would have to be 1298(?) identical topics on the page before you needed three characters of garbage in the unique ID.
Benefits
- The URL is 100% human readable. Even the micro unique ID is mostly of human-meaningful. It's a counter for the reused topic name. If the same article is proposed for deletion 3 times, the ID on the URL is absolutely clear, meaningful, and important. It clearly shows that this is the article's third deletion discussion. The ID only gets fuzzy when you move from digits to letters, and it doesn't get ugly until it's more than one character.
- The URL has zero redundant bloat added to it.
- The large majority are unique to start with. They can be blindly typed by a human who knows the pagename and topicname.
- Even if the topic name is a repeat, a human can blindly add a separator and 1 to guess the actual URL. In the worst case someone could even start incrementing the 1, manually searching for the desired address.
The only downside I can see is that you may need a database access to grab your internal UUID. A database access is an excellent trade off for better human usability. Currently busy topics will be cache hits anyway, minimizing the cost.