My personal observations (that I entered yesterday and yet never submitted):

I agree with this conceptually; we should at least provide suggestions for how this should be done, with an eye towards enabling more automation.

Following this shouldn't be any sort of requirement at this point. maybe later. The only requirement should be that if a script has the prescribed name, then it MUST follow the format

I don't understand why you would require something to substitute in %{version} and such when those could be passed in the environment or as positional arguments. Is there some kind of security consideration here that I'm not understanding?

What is the state of the various bits of automation which would use this? Is there a proposal elsewhere to set up automated checks based on this? Is there a ticket or PR against fedpkg or some adjacent tool to handle passing the information to the script to automate the downloads?

I don't understand why you would require something to substitute in %{version} and such when those could be passed in the environment or as positional arguments. Is there some kind of security consideration here that I'm not understanding?

The script will live outside of the spec file. So macros expansion will not work. Therefore I suggested to use only these ones. But yes, passing them as positional arguments is option too. And likely better option :)

What is the state of the various bits of automation which would use this? Is there a proposal elsewhere to set up automated checks based on this? Is there a ticket or PR against fedpkg or some adjacent tool to handle passing the information to the script to automate the downloads?

Packit will find this beneficial. Packit can create new version of package when there is upstream release, but only if SOURCE is URL. When it is file there's nothing to do.

And I guess QA can later use it too, to determine if there are potential differences.

Note that a similar RFC in the past has been stalled in bikeshedding:
https://pagure.io/packaging-committee/issue/1132

I offered to implement support for something like this in spectool, but since it couldn't be agreed on what should be done, I didn't implement it. (maybe I just should do something ...)

I keep thinking about implementing a harness to run OBS source services too... We have a few of them packaged, we just don't provide a mechanism to run them right now.