[class.spaceship] lacks to specify the behavior if the defined expression for synthesized three-way comparison is ill-formed

Consider this example:

struct C{
   int operator <=>(C const&) const noexcept = default;
   int a = 0;
};
int main(){
    using type = decltype(&C::operator<=>);
}

GCC:

<source>:8:39: error: use of deleted function 'constexpr int C::operator<=>(const C&) const'
    8 |     using type = decltype(&C::operator<=>);
      |                                       ^~~
<source>:4:8: note: 'constexpr int C::operator<=>(const C&) const' is implicitly deleted because the default definition would be ill-formed:
    4 |    int operator <=>(C const&) const noexcept = default;
      |        ^~~~~~~~
<source>:5:8: error: three-way comparison of 'C::a' has type 'std::strong_ordering', which does not convert to 'int'
    5 |    int a = 0;

GCC and Clang have a divergence implementation on the point that if the defined expression is ill-formed. Specifically, the expanded list of subobjects for an object x of type C consists of {C::a}, where the synthesized three-way comparison is defined as static_cast<int>(a<=>a) as per [class.spaceship] p1.1. Since the operand of the operator <=> in the defined expression has type int, built-in expression interpretation applies to the operator, its type is std​::​strong_­ordering whose prvalue cannot be converted to type int. Thus, the defined expression static_cast<int>(a<=>a) is ill-formed, on this point, GCC thinks the defaulted three-way comparison function should be deleted while Clang thinks it's ok(not be deleted). However, [class.spaceship.note] p1 wants to imply something regarding this case. However, it's not a formal rule and no overload resolution performs in this case too.

Start with [class.spaceship] p1.1 and [class.spaceship.note] p1, then reproduce the linked GCC and Clang behavior using the C++ example in the issue. Done means the draft explicitly specifies what happens when the defined expression for a synthesized three-way comparison is ill-formed.