The instruction was not updated since it did not need an update. It still works as it did after release.
I replied to an user reporting it didn't work anymore, and since I know we changed many things in the way the menu works after that date, I assumed it was because of these changes but, of course, I couldn't possibly know without knowing exactly how that plugin works.
But please don't implement another Simconnect app since that just makes things more complex. We already have Simvars that anyone can send to MSFS, but those need to work around the GSX MSFS menu specialities (e.g. always refresh menu before selecting an entry).
Just expose a public API from Couatl directly and let other developers build the needed tools. This way one could implement GSX into many other tools (e.g. in the Fenix EFB) without the need of yet again going through Simconnect.
I don't know how you could possibly say that, without knowing anything about how GSX really works, internally.
The only thing you see are the GSX L: variables being exposed, but that's just a way ( a hack ) to connect the HTML/JS menu to the Couatl scripting engine that runs the whole code but, those variables are only a consequence of that but, at the low level, what is really happening IS a Client-server Simconnect communication between the part of the GSX code that runs in Couatl with the GSX WASM module that makes the menu menu working using those variables.
This would be way more simpler and responsive, if GSX/Couatl were simply integrated with the Streamdeck SDK, bypassing that whole superstructure, removing the need of AAO which added an extra layer of abstraction, removing the need to read the tooltip and menu text files that contains the actual menu entries, when GSX could just call into the Streamdeck SDK instead and provide with all the required data directly, jumping over all of this.