This conveys spacing much better thanks to the separate echo line, even though I have a feeling this was done for portability as $'magic' might not be allowed everywhere.

I did it for spacing, and to to take fuller advantage of echo to have fewer \n sequences. Although it's true that $' ' is not POSIX and shouldn't be used in a #!/bin/sh script, this script is a bash script and $' ' is a available in bash on all systems. (ksh, zsh, and probably some other shells also have $' ', but not all POSIX-compatible shells have it.)

Regarding spacing, the table is currently formatted using printf and this has the advantage that its own output spacing can be adjusted by, for example, changing 14 to 15. But I originally used printf for it because I was preferring printf to echo, because originally I was doing this inline in Makefile, and a Makefile runs commands using /bin/sh (unless SHELL is assigned in the Makefile itself). This was to follow the practice of avoiding echo in portable sh scripts, at least when displaying data read from files.

But that is not necessary in a #!/bin/bash script, where we know how echo works and where echo doesn't expand escape sequences by default. So it would actually be okay, at this point, to go back to displaying the table this way:

echo
echo 'The VERSION must be the same in all locations, and so must the HEAD and tag SHA'
echo "VERSION file   = $version_version"
echo "changes.rst    = $changes_version"
echo "Latest tag     = $latest_tag"
echo "HEAD SHA       = $head_sha"
echo "Latest tag SHA = $latest_tag_sha"

This is arguably more readable, and arguably conveys spacing the best. I'd be happy to change it to this if you like.

(Another option could be to go in the opposite direction and make this check-version.sh script, and maybe the build-release.sh script as well, a #!/bin/sh script, which is feasible.)

This is arguably more readable, and arguably conveys spacing the best. I'd be happy to change it to this if you like.
(Another option could be to go in the opposite direction and make this check-version.sh script, and maybe the build-release.sh script as well, a #!/bin/sh script, which is feasible.)

Since trap is supported in POSIX shells and thus sh, making these scripts more portable seems valuable, even though I think that as the project currently is setup there isn't any need as it's only me using them.
Alternatives involve running these on CI which also supports bash everywhere (at least so it seems).

If you think there is benefits to portability assuming that one day CI can perform trusted publishes, I think it's fair to adjust for portability next time you touch them. Otherwise, it would be just as fair to change printf with echo as shown above. It's perfectly optional as well.

The desired interaction of trap and set -e may be achievable in sh. Even if not, we don't have to use trap; it can be replaced even without making the control-flow logic more complicated or error prone. For example, the script could accept -q to not append the failure message, and otherwise invoke itself with -q, check the result, print the message if it failed, and exit with the original failing exit code. (There is also an argument to be made that set -e shouldn't be relied on at all.)

There are not many systems where bash doesn't exist and can't be made available. However, due to the problem described in 729372f--which only happens when MinGW make is being used on a native Windows system that has also WSL installed, and does not happen outside make nor on other systems--the scripts' bash hashbangs are written as #!/bin/bash rather than #!/usr/bin/env bash, and thus assume bash is in /bin.

Making them #!/bin/sh scripts would also fix that. It is even safer to assume sh is in bin than to assume env is in /usr/bin, so #!/usr/bin/env sh is rarely used. (Anyway, there is no corresponding WSL-related sh.exe in System32.) So, when combined with the other minor reasons for using #!/bin/sh, that is probably worth doing.

As you've suggested, next time I work on those scripts I'll look into making them POSIX sh scripts. However, this would be unrelated to facilitating trusted publishing. CI does support bash everywhere, at least on runners hosted by GitHub Actions.