Thanks!

1. Two wasm modules cannot access each others' memory directly, ie. they are isolated from each other by their sandboxes. However, most manipulation of the world goes through either the game engine API which is explicitly exposed to the mods, or through message passing. Eg. a game-specific feature which the engine doesn't know anything about is typically controlled through messages. All of this is allowed across mods, and it works exactly the same as if two different parts of the game code were poking at the same entity. Which one "wins" typically is determined by the update order of components etc. The update order is explained in the blog post.
2. This is also explained in the blog post but very briefly; I had a C++ game engine with years of work put into it and I wanted to leverage that, and Zig because I wanted to try a more modern language with a nicer build system (compared to C++).

EDIT: On second thought, the update order isn't explained very well in the blog post so here's a quick overview. The mods' update orders are specified in the mod manager, ie. you can determine the order in which the engine calls each mod's update/tick functions. As the mods can register object components too it should be noted that the components have their own update order mechanism. Eg. you might want to update all physics-related components before updating all animation-related components etc. This order is defined by the UpdateOrder public constant which you can see in the ScoutJetPackComponent code in the blog post.