First, I want to say I'm very excited about the prospect of ownership-related features in general. Introducing a fundamentally new concept into a well-established language, in public, must be an immense task, and I appreciate the amount of thought and care it surely takes to navigate this.
This is where I'm struggling, personally. I am very much in this camp, but only in the absence of owned as an argument modifier. Without the argument modifier it's difficult for me to pin down what move is other than "compiler magic", which feels very much like a keyword*; but with the modifier it's clearly "just" an identity function that takes its argument as owned—something that falls naturally out of more fundamental concepts in the language. In a world with the argument modifiers move as a keyword is just syntax noise.
*I know there are "compiler magic" functions/intrinsics already (like unsafeBitCast), but those pass the duck test for "is a function" in a way that move() doesn't to my mind
owned and shared are discussed as future directions, but future directions aren't promises. I can meta-game and infer that these keywords are probably coming, but I think it's generally agreed that proposals should be evaluated on their own merits. Given the proposal on its own I have one piece of feedback, but in a hypothetical—but likely—future I have the opposite feedback.
In this case the difference is ultimately pretty minor, but I think it highlights some sort of impedance mismatch in communication. From my perspective as a random community member there's no roadmap; it's clear that this is related to ownership but what that means in specific terms is unknown. Should I expect this feature to land in a release on its own? Or should I expect more proposals that flesh out a bigger picture to target the same release? Does this go before 6.0, in which case we have a "source breaks are OK" escape hatch, or does it live indefinitely? It wasn't obvious to me before that @beccadax 's suggestion of quickly revising without a deprecation cycle is even an option. This is in contrast to core team members and others with more inside knowledge who surely have at least rough schedules and task orderings in mind.
Again, the social dynamics alone of pitching and landing such a large project are clearly gnarly—I very much appreciate, and do not envy, the core team in this regard. And I understand there are constraints that make more explicit communication difficult or undesirable. Clearly there's not an easy win-win answer here—but as a point of reference I feel like I remember much of async as being a set of proposals posted in quick succession that inter-referenced each other. This obviously has its own set of challenges and tradeoffs, but it did make it clear that they were a family of sub-features that were, generally, expected to ship in the same release. (I'll also admit that for various reasons I wasn't actually following the forums closely at that point in time, so I may be off base here)