Why do you need to change the data format to make it faster (at the cost of making it harder to work with to end users)? The data is the same as it was at the beginning, it doesn't justify a technical redesign. Why not just create accelerators based on an intermediat format?
Properly normalized data isn't just faster, it's also easier to work with for the end user. There are much less exceptions, edge cases and snafus to work around and test for. If you're talking about the transition period between formats, well yeah, you're gonna see things breaking. But these were already broken, just not in apparent ways. In the end, everybody wins.
> Properly normalized data isn't just faster, it's also easier to work with for the end user.
Extracting and reusing data, yes. Getting it into the tool in the first place, no way. Tools that won't even allow you to save your data and make it persistent until you conform to every single integrity requirement are a nightmare for end users.
People doing mapping tasks will use an editor and not really see the change.
People consuming the data will also mostly use tools, tools that likely run much faster.
I've written some code to chop up overlapping gis areas into ways and relations (to match the current data model of references to shared nodes). The input to that code is pretty close to the proposed data model, so not going to be more difficult to do that processing (as an example of a task that doesn't just use 3rd party tools).