As Baloo quoted - we do plan to improve URLs for users by using an ID hash rather than an actual module prefix and real ID. The reason for doing that is to hide the actual number of users to avoid that "network is too small" effect, and also simplify the URL.

To answer Baloo - yes, the change could be a problem for already indexed profile URLs, so along with the change, we will provide instructions for setting permanent redirects for old URLs to maintain continuity and preserve links. 

As for URLs like, say "site.com/username", also known as "Vanity URLs", we would rather not to that, to be honest. Here's why:

- First, using /page/ prefix for UNA-powered content is important. You site may end have other software installed, or will have something installed in the future, which may need to use certain URLs names in the root domain. You may also want to relocate entire UNA installation to another domain or a subfolder in the future and having /page/ in URLs helps to identify and redirect them correctly when needed. 

- Second, allowing vanity URLs in the root or even in /page/ is problematic as those may clash with other pages requiring same names, some of which we can't account for. For example, someone takes a handle like /about. Then, you'd be unable to create a page /about with same address. Or worse, if someone creates a URL that matches a URL used by a module you install at a later stage. 

- Third, if you allow identifying "names" in URLs, you'd have to allow them to be editable. Say, in case someone makes a mistake or wants to change their name later. If they do, plenty of external links and mentions would break. 

All in all - it is possible, but not at all simple to implement vanity URLs. It's a kind of feature that may bring a lot of complexity for very little gain. After the planned update, we'd have URLs like, say, "site.com/page/2a37s89" or similar. I believe that'd do the job.