The use of _dynamicReplacement
As mentioned in the proposal, this will be replaced by some non-underscored attribute of similar capabilities.
We do not consider having to stabilize the dynamic member replacement feature in order to land this feature. Note that the existence of any dynamic functions is completely hidden from users already; it only leaks through this @_dynamicReplacement attribute; Our goal would be to not have users worry about how the remote function is "getting there", it may be the _dynamicMember replacement or some other underlying mechanism, it doesn't really matter as far as transport implementors are concerned.
Another future direction which impacts this is Synthesis of _remote and well-defined Envelope<Message> functions because if we were able to get away with not having to rely on the source generation to fill in _remote functions, there would not be any need for those replacements, as a transport could completely implement it all within library code.
This is a very tricky problem though, and it'd likely both need Variadic Generics as well as some more general and powerful meta-programming tools to make this a reality. There are also concerns about forming a "general message type" as we don't know yet about some of the specific requirements of a few transports we are investigating. We don't want to lock in this part of the design into the language unless we are 100% confident it would support all future transport implementations - we are working on figuring this out though.