before I dig deep with specifics, I would want to emphasize that the localization is still in the beta phase when we consider requirements of every country.
advanced users can easily grasp how things work but I do not think it would be easier for others. that being said, no one would need to create new tax codes once the localizations are fully implemented. so i guess this is a necessary change for the better.
until something is developed to set which tax codes are selectable on which transaction forms, users will be bombarded with a confusing list of tax codes. the developer is aware of the issue and some tweaks can be expected in the near future.
also, there are improvements which needs to be further improved based on different localization requirements. one such improvement needed is explained here.
users would be willing to have separate records when the taxation requirements change but I do not think they would want separate records because of changes to the program. it raises doubts about the program being a perpetual system. the program is not expected to produce scattered reports based on the time of new feature additions. merging existing tax codes was suggested here which would enable compatibility of old transactions with the new localization features.
@lubos i would also suggest to have a reference log and instructions for every localization when the localization moves to the stable phase. this would help users understand how to use the localization features and to modify them when the requirements change. also, dependency on users who created the localizations initially would be reduced when tax regulations change in the future.