During the, very long, discussion it became apparent that different tools have different design requirements on a lock file. So it's not really clear what will happen to other lock files.
It may be this new lock file acts as an interchange format, that all tools can consume or produce, but not something they internally use.
Though, maybe we're lucky and tools will be able to use it directly, or we might have to wait for a new version of the standard once tools have been able to work with it long enough to know the deficiencies.
Non-lock files, like pyroject.toml and requirements.in remain unaffected.
pyproject.toml is still fundamentally intended to be an input file that describes abstract dependencies for a single package. Lock files describe entire environments, or at least entire change-sets for an environment, and specify everything - pinned versions, including for transitive dependencies, and also hashes and other expectations for the install artifacts.
Tools that use custom lock files are at liberty to switch over, and any concerns about migration, backwards compatibility etc. are up to them. Several major tool authors were consulted for the design repeatedly across the discussion thread, over a period of months (and this is just the latest attempt at the design task; the total history is much longer).
It does, and that is the plan as far as I can tell. The prior discussion in the thread, as well as the commit history for the PEP (https://github.com/python/peps/commits/main/peps/pep-0751.rs...), shows pretty clear intent to take all of their needs into consideration.
It may be this new lock file acts as an interchange format, that all tools can consume or produce, but not something they internally use.
Though, maybe we're lucky and tools will be able to use it directly, or we might have to wait for a new version of the standard once tools have been able to work with it long enough to know the deficiencies.
Non-lock files, like pyroject.toml and requirements.in remain unaffected.