Potential of multiple linear memories for speed and stability in threading.

This is not an "issue" for the current proposal, more of a remark, but curious if people see any use for it.

With the current proposal, the way a multi-threaded C++ program would typically be represented is a single shared linear memory and multiple instances of a module, since a C++ compiler can't separate shared memory from non-shared.

But there are advantages if a language front-end would be able to separate shared memory from non-shared (once we have support for multiple memories in an instance). The default one could be non-shared, with 1 or more additional shared memories.

It would improve safety/stability, since you can now guarantee all that non-shared memory cannot be trampled upon by other threads, allowing wasm to effectively help you isolate threading issues.

It could also help speed, since any run-time functions (such as e.g. a memory manager) can be specialized to non-multi-threaded versions. In C++ currently that is all or nothing, and seems to default to supporting multi-threaded for most compilers even in mostly single-threaded programs.

The problem is of course lack of languages that currently support this.

No files, tests, or implementation entry points are named. Start by reviewing the current threads proposal and its support for multiple memories, then assess whether separate shared and non-shared memories are intended as a concrete feature. The issue does not define an implementation scope or a verifiable done condition.