Is raising of unexpected exception considered as an implementation defect?
Follow-up question for Why conversion (unsigned long long)DBL_MAX (or FLT_MAX) causes raising of FE_INEXACT as well?.
Is raising of unexpected exception (FE_INEXACT) considered as an implementation defect?
Notes:

User @Nate Eldredge confirms that on AArch64 FE_INEXACT is not raised.
All the hardware powered by Infineon TriCore does not raise FE_INEXACT, because the condition to raise FE_INEXACT is inexact && ! invalid. I.e. it is not possible to have both FE_INEXACT and FE_INVALID raised.

Reason of the question: need to precisely interpret / classify / categorize this case.

One of the answers in the other question says this is undefined behavior. That means anything is permitted, so no behavior could be considered a defect.

Is it considered a defect by whom?

By the end user. The end user expects only FE_INVALID. However, the implementation raises FE_INEXACT as well. Does IEEE 754 permit raising of FE_INEXACT in addition to required FE_INVALID? For example, one my colleague does not see in C / IEEE 754 any direct prohibitions to raise FE_INEXACT in this case. What is your view?

@Barmar When the C standard does not define a behavior, the behavior may be defined, partially or completely, by other standards (https://stackoverflow.com/questions/65106621/fp-invalid-operation-contradiction-between-c-ub-and-ieee-754-wdb/65107366#65107366). In this case it is IEEE 754. Also (from C standard): Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment.

This sounds more like a quality of implementation issue.
