> * Mention the new build requirement in What's New in Python 3.11.
> * Modify configure script to make it fail if the IEEE 754 support is missing.
> * Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.

That sounds fine.

> * Remove @requires_IEEE_754 decorator of test.support and tests.

I'd suggest leaving those decorators. Some of the tests are used by Python implementations other than CPython, and we're not requiring IEEE 754 on all Python implementations.

> * Remove "unknown_format" code path of pack/unpack functions like _PyFloat_Pack8() (see bpo-46906 which proposes to make these functions public).

Sounds fine.

> platforms with float larger than 64-bit

I'm assuming you mean Python "float" / C "double" here. There seems to be a persistent misunderstanding here, and I'd really like to be sure that everyone understands what the current code is doing before changing anything. There are *no* platforms that Python cares about where the C double is larger than 64-bits, and as far as I'm aware there never have been.

What there *is* is a set of platforms where the C double is IEEE 754 binary64 format, but where arithmetic operations between doubles may be performed in extended precision (usually 64-bit precision), so those arithmetic operations don't conform strictly to IEEE 754 semantics. Most flavours of Linux on x86 match that description.

Then there's a (possibly empty, but we don't know that for sure) subset of *that* set of platforms where we don't know how to temporarily enforce 53-bit precision during numeric parsing / formatting operations.

It's that second subset where dtoa.c can't be used, and where we need the fallback of the "legacy" float repr.

I'd be more than happy to deprecate and eventually remove support for the legacy float repr, but I think it's too big a change to make for 3.11: we'd need to deprecate the support for 3.11 and eventually remove it in 3.13.