Thanks for writing this up. I only got around to replying to this yet so please excuse me if I am re-iterating points that have been made upthread. In general, I agree with the sentiment that the approachability of data-race safety is currently too hard and requires developers to think about it too early. This goes against the progressive disclosure goal of the language.
One of the largest offenders that leads to developers having to learn concurrency concepts early on is how non-Sendable types interact with async code. I think the pitch to [Pitch] Inherit isolation by default for async functions will solve a huge deal of these issues. The only other remaining thing that I see people running into very early on are mutable global variables (even of Sendable) types. Addressing those two should in my opinion already resolve a great deal of data race errors.
Now the vision doc calls out a new mode that puts a whole module into a @MainActor isolation by default mode . While I understand this from a UI application developer perspective quite well, I am very concerned of this mode for server applications and also for more complicated CLI apps. Specifically, server applications are often expected to run highly concurrent and we don't want to have users automatically opt-in to a single isolation domain. I can already foresee the amount of discussion around slow server performance if we make that the default mode for executableTargets.
If we think having such a mode is good and doesn't create language dialect problem then I would at least suggest that we don't enable this mode by default for executable targets but rather enable the mode by default for iOS/macOS/... apps. This can be decided by IDEs such as Xcode but I wouldn't make it a default in SwiftPM.