Complexity scares me more than it does Ales. Every year WikiTree gets more complex and I long for simplicity. For me, for the infrastructure we have to support, for members. Increasing complexity is almost inevitable in a system like ours, and I am resigned to some, but still I fight it when I can. :-)
Technically speaking, this change would mean adapting our systems for displaying profiles and editing for them, for creating new profiles, for matching and merging them, for comparing and creating through GEDCOMs and WikiTree X, and more. Every system would need updating and would get just a little bit more complex. I also think it would mean taking WikiTree offline while we rebuild the database to allow location names to be longer. This might seem like a small thing in the long run but it's more daunting than most people might assume.
Even more significantly, this might affect, or at least its effects should be considered, in every single place we display a location name. Is the user seeing an old or a current location? Do they need to see both? Do they know which one they are seeing? We'd have to think about this for search forms and search results, index pages, lists, family trees, a ton of display widgets, independent apps using the API and database dumps, and more.
Users would have to understand what they are entering and why. Some new users already have a hard time understanding our historical location names style rule. This would not make things easier to understand. Once over that initial hurdle it might be easier, but that initial hurdle would just be a little higher. (The hurdles a new user faces when trying to understand WikiTree are already very high.)
Some years ago we developed a plan for tackling the issues related to historical place names vs. current place names and location name normalization. Despite its disadvantages we decided to use FamilySearch's Place Names database. It has historical place names with corresponding geographic coordinates. We decided that if members started using the FamilySearch style we could later translate those into current names and coordinates where necessary. It could be done in various places, on the fly or in batches, and eventually used for matching. We didn't know exactly how that would work out, but figured it could be worked out. We haven't fully worked it out.
Many people don't know that even though Ales is a team member most of his work is completely independent. Frankly, I do not understand what he has been doing with place names in regards to normalizing them for his Map Navigator. Ales is a genius and mapping is his professional specialty. I don't presume to know a fraction of what he knows about this stuff, but he and I will talk. Maybe there is something more we can do utilizing WikiTree's relationship with FamilySearch.
By the way, many years ago, when we first started WikiTree, we left room in the database for geographic coordinates. But we have always decided against using them because maintaining them manually and collaboratively alongside manually-entered place names would be too confusing for users. We decided it would be better for us to automatically translate the place names using FamilySearch's database.
Some less ambitious style changes we might consider: We could clarify that if you don't know the historical place name you should enter the current name. With almost everything on WikiTree, some information is better than no information. Then, when you or someone else can add the historical name, you should. We could pair this with a clearer recommendation on when/why/how to explain the location name and how it relates to the current place name in the biography.
Chris