It would be even nicer, if the standard mention in a sentence that this is explicitly meant to be usable for the purpose of differentiating between utility and redirection errors.

So I would support updating the standard to require that n<&n and n>&n are always a no-op if fd n is open, except that if the shell normally closes fds > 2, that were opened with exec, when it executes a non-built-in utility, then applying n<&n or n>&n to such commands causes fd n to remain open.

The standard does not exist for your personal benefit, so I do not think it should bless your highly specific use case.

However, it would make sense to briefly mention the closing-high-FDs behavior as motivation. Something along the lines of Geoff's wording in the thread would be more than sufficient:

2.7.5 Duplicating a File Descriptor

The redirection operators:

[n]<&word

and:

[n]>&word

shall duplicate one input file descriptor or output file descriptor, respectively, from another, or shall close one. If word evaluates to one or more digits, the file descriptor denoted by n, or standard input or standard output, respectively, if n is not specified, shall be made to be a copy of the file descriptor denoted by word; if the digits in word do not represent an already open file descriptor, a redirection error shall result (see Section 2.8.1); if the file descriptor denoted by word represents an open file descriptor that is not open for input or open for output, respectively, a redirection error may result. If word and n evaluate to the same open file descriptor, or if n is not specified and word evaluates to 0 or 1, respectively, no duplication shall occur; if the shell would have closed the file descriptor because it was opened using exec and has a value greater than 2, when the redirection is being performed in a command that will execute a non-built-in utility, the file descriptor shall instead remain open when the utility is executed. If word evaluates to '−', then file descriptor n, or standard input or standard output, respectively, if n is not specified, shall be closed. Attempts to close a file descriptor that is not open shall not constitute an error. If word evaluates to something else, the behavior is unspecified.

so what about things like <1 or >0 ?

As far as I understand the wording about the n = word case, wouldn't that also mean that e.g.:
   exec 8<some file; exec 8<8; utility
would now be expected to keep FD 8 open when invoking utility

exec 8<somefile; exec 8<&8; utility

if the shell would have closed the file descriptor because it was opened using exec and has a value greater than 2, when the redirection is being performed in a command that will execute a non-built-in utility, the file descriptor shall instead remain open when the utility is executed

What I at least would want to avoid is that people might ever come across this issue or the corresponding mailing list thread and assume that this is now the way to portably differentiate between utility non-zero exit status and redirection error, when wouldn't be really the case.

If it is a no-op then it can't fail. So the only possible failure case would be in the "remain open" requirement. In practice this will involve calling fcntl() to clear the FD_CLOEXEC flag, which could indeed fail because of something like resource exhaustion, but I don't see that it increases the likelihood of internal shell failure significantly. Any command execution can fail within the shell because of resource exhaustion (e.g. fork() failure) before it gets as far as doing the exec.

If you don't think it is, fine for me,... we can still make the change here, but should also mention that this cannot be expected to portably allow the above.

If you think it is and if you think that "briefly mentioning the closing-high-FDs behavior as motivation" is enough to also make sure that this is understood by any shell implementer, then I'm all good.