I think this proposal is really great, fundamentally, although there is a huge amount of design questions.
One of the big selling points of Rust is its robustness, and it should not be compromised here IMO.
Personally I think it's very important to support lockfiles inside the toml as well as not do assumptions about editions, aka keeping the behaviour of 2015 being default if not specified otherwise, although as it's a new feature one has the opportunity to now default to a new edition like 2021 or even 2024 (basically whatever is newest at point of stabilization, then not changing it). Otherwise it will harm the edition mechanism: upgrades of the toolchain should not introduce breakage, this is one of the core pieces of the editions RFC.
Especially when it comes to editions, people will probably omit it more often than not and then run into problems after upgrading their toolchain.
For inline lockfiles we'd probably benefit from a more compact way of specifying lockfiles, ideally just the list of version numbers of all used crates. Then cargo can infer the rest by running the classical resolver algorithm and pretending that the non-mentioned version numbers don't exist/were yanked/never published. Hashes, while great, for .lock files, are maybe not required that much. As a default behaviour, if no inline lockfile is present, the script could just create a standard lock file in the same directory with the name of the .rs plus ".lock" at the end. Then it's up to users whether they want to inline the lockfile (via a command) or whether they want to distribute that separate file (or not distribute it and take the risk of breakage onto them).