The file format used for NavData/SIDs/STARs being in a "text"format would be a big PLUS.Level-D and PMDG, to mention two I know of, currently do.Where the end user can easily edit the files with Notepadto correct errors between monthly cycle updates.This also means there can be multiple sources for customprocedure (SID/STAR) files for user aircraft.

I do not agree with you, also for developers there are huge advantages:1. There is always Navdata available, incl SID/STARs if necessarry2. There would be a common/public set of C++ libraries to accomodate all functionality for a simple GPS to a complex FMC. The truth is: IRL there is already a standard and it's called ARINC 424.It accomodates Boeing, Airbus, Embraer, Garmin, you name them.... So what is different in the virtual world, why is it so difficult to arrange?

If the add-on developers changed to a new common system then they would have to continue issuing updates in the old format or provide all previous puchasers with a (free?) update to accept the new system. Either would be a major disadvantage. Of course developers could just abandon previous purchasers, but think of the outcry that would cause here.Real-world FMC suppliers haven't agreed a common format, even with all their resources, so it's unlikely FS developers could., ARINC 424 is a standard for the preparation and transmission of data for assembly of airborne navigation system data bases. It defines the format of individual records but doesn't define how those records are to be assembled into a useable database for a particular FMC. This individual FMC suppliers have to do that