Summary: Pointers into wasm linear memory are currently represented in wasm programs as 32-bit unsigned integers. This has two consequences considered negative by developers: heap sizes are limited to 4GB (when computers have much more physical RAM than that), and C/C++/Rust code bases that target wasm must be compatible with a 32-bit pointer size (when native deployment almost always can assume a 64-bit pointer). The memory64 proposal removes these restrictions by allowing heaps to be larger than 4GB and to be addressed using 64-bit integers.
Spec stability and issues: The spec is stable and appears uncontroversial. However, the cost of bounds-checking 64-bit accesses remains a concern (and of course memory consumption will increase with 64-bit pointers). Adopters of 64-bit pointers may find that there's still no such thing as a free lunch.
Security & privacy: There might be some generalized concern about how allocating very large memories can be used to reduce the efficacy of ASLR. Wasm memories will be capped at the max size set by the JS engine, currently 8GB. Any increase of that limit for JS+Wasm will only be after discussions that take that concern into account, and so the memory64 work does not bring any new concerns to the table in that regard.
Platform coverage: All (including also 32-bit platforms, to simplify deployment to the web)
Preference: javascript.options.wasm_memory64, eventually.
Devtools bug: None at this time.
Other browsers:
Chrome: is prototyping this and leading the spec work
Safari: I'm aware of no signals
Web-platform-tests: To appear