Why? I want to fly the same routes that are flown by the real airliners. And I do not want to have a perfect knowledge of the future. Pilots of the two flights from my Flightradar24 example definitely did not know the exact approach trajectory before the flight. They had to use their brains and fingers to reprogram those MCDUs. That's real and that's what I want. No ATC software can simulate this on generic bases. PF3 is the only one that enabled me to do it at least on the airport–specific bases...
I do not consider SID/STAR names important and do not expect PF3 to read them from (whatever) NAV data source.
Why? In 99.7 %, there really is just one right standard procedure for a given combination of variables (runway, flight plan, time of day, etc.). Reading it by PF3 will not add any information. And it will not even add a lot of realism, as real-world controllers usually do not spell the procedures' names letter by letter. When PF3 instructs you to fly the "Sierra Papa" procedure, it is all you need to know. It may seem contradictory to my previous point about variability, but it is not. The name of the procedure does not matter to me, this is a known and static element. I look for some variability of the procedure's execution. This was actually the reason I abandoned the development of Navigraph/NavData integration to Randomizer.
In a nutshell, I don't think PF3 needs any changes or improvements in its handling of SIDs and STARs. Actually, they can be contra-productive as they could limit its flexibility – one of the reasons PF3 is the best! Personally, with a little help of Randomizer, I have everything I ever wanted and maybe a bit more
