On page 2494, line 80985, insert:

If any part of {location} is quoted it shall not be recognized as part of the redirection expression.

% cat /tmp/austin-1892.sh
# Use eval to keep fatal errors contained.
eval 'echo hi {fd}>&1'
eval 'echo hi \{fd}>&1'
eval 'echo hi {\fd}>&1'
% bash /tmp/austin-1892.sh
hi
hi {fd}
hi {fd}
% ksh /tmp/austin-1892.sh
hi
hi {fd}
/tmp/austin-1892.sh[4]: eval[1]: \fd: invalid variable name
% zsh /tmp/austin-1892.sh
hi
(eval):1: parse error near `}'
hi {fd}

Well if this is the case, then it's strange that the 2024 edition standardised (in the sense of "allowed") behaviour which make some of the previously only forms non-portable.

Likewise, the standard does not permit the useful feature:

{var}>file

and related redirections because the grammar requires:

echo foo {var}>file

to be parsed such that {var} is a WORD to be expanded and passed to echo.

If that is indeed meant to be, than I'd revise my desired action, to add a warning or something alike explicitly mentioning that:
a) it's undefined whether or not quoting of {location} causes it to be not taken as part of the redirection
b) and consequently that any form where {location} is not separated by whitespace from redir-op is no longer guaranteed to be portable.

If the string contains at least three characters, begins with a <left-curly-bracket> ('{') and ends with a <right-curly-bracket> ('}'), and the delimiter character is one of '<' or '>', the token identifier IO_LOCATION may result; if the result is not IO_LOCATION, the token identifier TOKEN shall result.

echo hi \{fd}>&1

If the string consists solely of digits and the delimiter character is one of '<' or '>', the token identifier IO_NUMBER shall result.

If n is quoted, the number shall not be recognized ...

If any part of n is quoted, the number shall not be recognized ...