I tend to think the OP rases a legitimate concern, though braking strict aliasing is not the right solution IMO. I rather think std::float64_t should really be a typedef to a standard floating point type (typically double) when and only when that type is an IEC60559 Binary64.

The argument in P1467R9 that the get_exponent function below is moot on a IEC559 platform.
    int get_exponent(double x) { /* ... */ }
    int get_exponent(std::float64_t x) { /* ... */ }

If both double and std::float64_t have identical representation, behavior and intent, then I expect both overloads of get_exponent will have identical function body implementation with indistinguishable behavior for every pair of equivalent double/std::float64_t inputs. This situation makes overloading both useless, and a burden: implement identical code with identical behavior for types with identical behavior and identical representation. Not to mention all possible function signatures using double would often also need to be deduplicated.

Now on platforms that do not support IEC60559, then it is totally fine to have float64_t be a type distinct from the standard double since, for instance the get_exponent function above might certainly have different implementation, with possibly different.

But at least if the platform is IEC60559, it should really use a standard floating type as a typedef for std::floatN_t.

On August 26, 2025 6:53:48 p.m. EDT, Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]> wrote:
>Following up to my own email:
>
>> The C++ standard does NOT allow one of double or std::float64_t to be a typedef of the other.
>> I don't have a clear understanding of why this choice was made.
>
>P1467R9 says the strongest argument against allowing aliasing [in the sense of typedef] of standard types is to allow overload sets such as:
>
> int get_exponent(double x) { /* ... */ }
> int get_exponent(std::float64_t x) { /* ... */ }
>
>Note that allowing aliasing in the sense of making another exception to the strict aliasing rule so as to allow reinterpret_cast would not affect overload resolution.
>
>
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals