we really should stop with the “fancy” url thing in admin… /admin/users/1/sam … is a perfectly fine URL for an admin interface, plus knowing the user_id is actually handy sometimes when it comes to admin tasks.
So far, the blocked usernames only contain confusing usernames (that look official or unintentional), not ones that break the system.
This list is admin-editable, nothing is preventing the admin from removing entries. This would have non-obvious side effects.
If I understand correctly, changing the default won’t affect systems which already customized the list, for example by adding an entry.
I have a strong feeling that there are more cases like this. I think that account-created is safe only by coincidence, not by careful consideration (“there could be a username here, so let’s add an invalid character…”).
Also, I don’t see the drawback: /admin/users/1/sam is perfectly fine for the admin’s eyes (heck, t/usernames-in-admin-urls-cause-routing-problems/31825 is fine for everyone’s eyes!), still has the slug (which is nice), and even works as a permalink across username changes!
It would also fix some issues for free: For example, after renaming a user, the back-functionality breaks, since the old URLS 404.
As working on the Unicode username support, the first step would be relaxing username constraints in routes. And I will also apply /admin/users/1/sam to admin routes.