This is still working correctly. The layer of our data is higher than the default data. We are using this from ASOBO/MS-recommended logic (according to the official, public SDK) since SU3.
You can test this yourself: enter any non-existing airports in the stock data (e.g., EDDT), and look for any non-existing tailored procedures in the EFB (e.g., NZQN RNAV 05-Y, RNAV-F, …).
In all cases, you will see that the sim uses our data over the stock data.
We would see many more reports when our data did not work as expected.
Back to the scenery issue:
I am not aware (and it looks like WT too) of any change (at least an official change) between SU4 and SU5, but when you are using a workaround in one of the previous versions that does not work any longer in the newer version without fixing the root cause, you can’t blame us, nor can you expect us to provide another workaround.
The root cause is that the scenery designer does not follow the public, official SDK, and that is the only error here. Not ASOBO/MS, not Navigraph, nor other devs/applications.
We have written an FAQ with missing information about the SIM and step-by-step instructions on how to fix it and/or find the reason. In this FAQ, we don’t recommend re-ordering packages due to other side effects. This FAQ is not new; it has existed since SU3.
The conclusion here is:
Report this to the 3rd-party scenery designer to disable/delete “removing waypoints,” and ensure the scenery is 100% SU3+ compatible and follows the SDK rules.
Also, we must perform many checks before a new SU comes out. We are fixing bugs after reports. I see this as our part in our business and as our service. I would expect the same for other companies, regardless of whether free- or payware.
Cheers
Richard