I see several posts asking what is/isn't possible with WASM and pointing to the advanced displays already developed.
So a couple things to point out, since glass is my specialty in my job, with the caveat that I have been heads down on work and not paying much attention to the latest FS updates.
1: (See caveat) So far the only "advanced" display is the G1000. So for starters, try comparing the terrain and weather radar displays of the 737NG, the A320 family, the PL-21, and a wide range of other advanced glass displays. Spoiler alert: They are VASTLY different from eachother.
2: Compare the navigation symbols for waypoints and flightplans etc. You will find commonality and diversity.
3: Compare the synthetic vision of the Garmin displays with the Proline Fusion, the various HUD SVS displays, the Honeywell Primus Apex (I think that's what Dassault or Gulfstream use in their jets, I forget which). Again, considerable differences not only in terrain rendering but also airport markers.
4: On the topic of airport displays on navigation displays, again lots of variety.
5: Unless provided access, no IR/TV cam views for enhanced vision displays on HUDs, or taxi cams in the cockpit.
Now a quick break before I continue on other points. What do all of the above have in common? Advanced raster image generation. Not possible with a simple 2D vector graphics library. If, and this is a big if (Those who know, can't say due to NDA, those who don't, don't know for certain), If Asobo has designed their background graphics engine to interface with the HTML or WASM or whatever they use specifically for the G1000, then it is tantamount to absolutely useless for most of the common avionics suites in use in other aircraft, beyond the most basic of functions (magenta line, text, compass rose or ADI/VSI/ASI/Alt/Engine instruments etc). Forget about custom designing advanced map and navigation displays. The current advantage of even the old FS9/FSX display system is that we had direct access to the raw image buffer for each gauge, and could use whatever rendering method we liked for advanced raster image generation. With P3D's PDK it got even better because we no longer needed to implement obscure weird low level CPU/GPU interfaces to get images that had been rapidly generated on the video card into the CPU buffer we had access to for the gauge image, which then went back onto the video card for display in the sim. Instead we got direct access to the DirectX texture surfaces which are mapped to the 3D model or displayed on the screen in 2D popups. This allows use of custom shaders for extremely efficient and rapid raster image generation which is so critical for navigation displays. It also allows considerable streamlining of rendering arrays of small objects like VOR/airport/Waypoint symbols. All of this disappears when locked down to a 2D vector library with no access to the underlying 3D rendering engine objects.
The mention of lack of thread support is another concerning item, even if a sandboxed file access is granted. Sometimes files are large enough that they need to be loaded on the fly, or conducting searches/indexing in them once loaded in memory needs to be threaded to run in parallel or turn the sim into a slide show every now and then.
Next, there are a good many windows and other external libraries used by developers that may not necessarily be available in WASM, unless specifically granted access.
And another item: Debugging. Visual Studio has an exceptionally great debugger allowing the use of breakpoints to intercept code execution wherever we like and examine the state of variables and objects and even raw process memory (a critical item. I have lost count of the number of occasions I have been able to trace corrupted memory via direct views of raw memory and working through ASM registers etc). I have my doubts as to whether WASM will support such low level debugging, which gets more and more critical the more complex an aircraft becomes.
Oh, and one last item: Forget about using the F1 or RXP GTN/GNS/G500/G600 gauges which use the actual Garmin trainers. That involves extremely low level C++ inter-process communications which WASM is explicitly designed to *prevent* with its sandboxing.
Another last edit: From the comments about speed of execution, forget about external flight models, where speed of execution is absolutely *critical* for best performance.