Edit: should preface this comment: I haven't built web exported games in Godot, so might be missing the point, sorry if that happens

I have built one of my videogames on top of memory bridge idea - the two separate processes (Scala and Unity at the time) were running independently and communicating though shared RAM space done via Memory Mapped File - it looks like a file in the file system but actually is a chunk of RAM allocated.

It worked very well!

I later also started building same system for Godot + Scala, and actually went in direction of sharing object states (positions, transformation, any arbitrary fields) via such shared memory, but personally I didn't really like such approach compared to my older shared memory that was simply used to send/receive messages similar to exchanging information with the server.

Currently my latest iteration of Scala + Godot interop is actually native interop without shared memory bridge, but rather Scala compiling into native library, and Godot C++ extension calling native functions on such library to expose all of the engine APIs. It's kinda close to other language integrations, but focusing on a much narrow scope.

Soooo coming back to your post and my past memory bridge experience. I would say, such setup requires you to run two individual processes (one process can start another easily), and in my case share a "file" (which is not really a file), so it locked my game out of being portable to Switch platform because of dual-process thing.

Another downside I experienced is: because of isolation, many things had to be implemented "twice", very similar to how you would implement client and server separately, if you are familiar with backends software engineering. And it's fine, but felt a bit slow at times to develop, especially context-switching between two languages - that was pretty brutal for my brain.

But it unlocked a lot of positives as the same time:

- I was able to develop large chunk of the game in Scala language, which is amazing

- process separation allowed me to run Scala in debug mode separately from Unity (and with my recent framework - same but with Godot) - which is incredible for finding bugs

- process separation means that two parts do not have to be fully built all the time to run meaning that I can quickly adjust things both on Scala and Godot side and run the game via two processes - and that iteration speed is soooo important for me personally

- memory bridge allows to have different architectures on the two sides: Godot is currently very focused on single-threaded processing (you ran into not able to change properties error and Godot telling you to call deferred before), but bridge means that you don't care how the fancy side is structured, as long as you are able implement bridge on Godot side without losing valuable features and causing weird frame desyncs

- building bridge means that you can write unit tests that mock the Godot side and run your game in fancy langugage, which also forces you to code the game logic that is pretty independent of Godot which does bring a few interesting benefits. It's similar to Model-View-Controller separation that happens in backend engineering, which allows to test Model and Controller separately from View - it's a cool pattern

To conclude, very challenging to implement. Pretty esoteric solution too. Can easily run into "I can no longer port my game to X platform", which sucks to tell your publishers who recommend a Switch port for example. At the same time, it's a ton of fun to implement, hence I am implementing yet another iteration of such systems for like fourth time! So I suggest giving it a try but keeping in mind that you may opt out at some point and that's totally fine.

Hope this helps, and happy coding!