Agreed.
I don’t think you can ignore this totally. If nothing else, the likelihood that script locks will not be updated in a timely manner, simply because people don’t have the infrastructure around scripts that they do around applications or libraries, means that out of date locks is a security issue, and should be covered under “Security implications” in the PEP. It may be that all we can do is educate people about the risks (which means we cover it under “How to teach this”) but it does need to be in there.
I’m also still concerned that the ergonomics of a 50-line script with a 300-line lock data block are pretty terrible. “Don’t use it if you don’t like it” is a fair answer here, but I think we need to acknowledge that it’s an issue.
Personally, I don’t have a good feel for how people will create scripts with embedded lock data. It’s not necessarily part of the PEP, but it is important context. Do you imagine some tool that takes a script with dependency metadata, and calculates a lockfile for it and appends that lockfile to the script? Or do you see people creating the block manually (i.e., creating a lockfile for the script dependencies using existing tools like pip lock, copy/pasting the file into the script, prepending a hash to each line and manually adding # /// lock … # ///)?
On the subject of tooling, what happens if the lock data doesn’t apply to the environment the script is running in? Does the answer differ if there’s also (unlocked) dependency metadata that can be used as a fallback? What if the dependency data and the lock data don’t match? Are tools expected to check? If they don’t, there’s another attack vector to consider.
Also, I’ll note that the current spec doesn’t say what tools must do when there’s more than one standardised block type. Blocks that have a non-standard type must be ignored, but if script and lock types are both standard, are tools allowed to only process one type? I think we have to allow that, for backward compatibility. So that means that a script with script and lock metadata would behave differently depending on the tool used to run it. Is that OK?
Regardless, the new PEP must specify what happens when a file has multiple metadata block types present. Simply because the current spec doesn’t say.
I’m not sure I agree - the fact that you can have multiple metadata blocks (of different types) in a script is a feature, and the ability to put them in different places is necessary (the fact that dependency data belongs at the top and lock data belongs at the bottom seems pretty self-evident to me). I’ll object strongly to any attempt to remove that flexibility. So we’re left with a situation where once we normalise the existence of a massive, opaque, script metadata block, we make it rather too easy to “hide” executable code:
# /// script
# dependencies = [ "requests" ]
# ///
import sys
import requests
requests.get(some_url)
# /// lock
# <lockfile data>
# ///
import os
os.system("rm -rf ~")
# /// dummy
# <more data that looks like a lockfile...>
# ///
Yes, “people should audit scripts before running them”, and yes, “once you run a script off the internet all bets are off”, but we shouldn’t be making attachers’ lives easy 
I’d argue that the original intent of PEP 723 was that metadata blocks would be human-readable and human-edited. Using them for machine-generated, opaque data blocks isn’t prohibited, but it doesn’t fit well with how I see script metadata being used. @sirosen mentioned this explicitly [above]
Assuming you manage to address these points in your PEP, though, I’m willing to sponsor it.
) Especially considering bundling the dependencies in the script bloats the distributable.
) of the comments here, I see a clear trend on “yes this is good” along with a lot of discussion around some details as well as a lot of discussion around what I’ll call “locking in general”.