The EFB currently loads “EFB-format” PLN files while MSFS 2020 loads “PLN files”. The formats are very similar with the EFB format currently supporting a small amount of optional additional content.
Only one small detail is preventing a ‘common subset’ PLN format being loadable in both MSFS2020 and 2024:
The departure runway in the MSFS 2020 format is:
<DeparturePosition>22</DeparturePosition>
In the EFB format, there are additional optional parameters but that same information can be represented with
<DepartureDetails>
<RunwayNumberFP>22</RunwayNumberFP>
</DepartureDetails>
The EFB departure runway format will cause 2020 to completely fail to load the PLN file while the EFB will load a PLN containing the <DeparturePosition> entry, but ignores it (TBH this is much better behaviour than the 1999 XML idea of rigid schema enforcement).
Suggestion:
Have the EFB accept that <DeparturePosition> entry if it’s in the PLN, but continue to give priority to the <DepartureDetails> as originally planned
That small change would enable some flight planners to produce ‘common subset’ PLN’s that would be loadable in both 2020 and 2024, without compromising anything the EFB is doing or planning to do in MSFS2024 onwards.
For large multiplayer groups sharing flightplans but also flying in both 2020 and 2024 (we have 2500 members) it really would be a significant advantage to be able to circulate a single PLN where that common subset suffices. I don’t think quietly accepting DeparturePosition if it’s in the file would impact the routine use of the EFB format. The suggestion just addresses this ‘subset’ use-case which would be useful for VFR flying.