🚀 go-pugleaf

1.6:
  "Implementation-defined behaviour - behaviour, for a correct program
   construct and correct data, that depends on the characteristics of
   the implementation and that each implementation shall document."

My question is, what form must the documentation take?  Does it need
to be intelligible and useful?  For example,

3.5.2.1:
  "Whether the high-order bit position of a 'plain' int bit-field is
   treated as a sign bit is implementation-defined. ...
   If insufficient space remains, whether a bit-field that does not fit
   is put into the next unit or overlaps adjacent units is 
   implementation-defined.  The order of allocation of bit-fields 
   within a unit (high-order to low-order or low-order to high-order) 
   is implementation-defined."

There are 2 x 2 x 2 obvious possibilities here.  However an 
implementation might want to do different things in different
circumstances while still documenting its behaviour.  Perhaps the
signedness of int bitfields depends on the number of bits.  The
Standard seems to place no limits on the complexity of the 
documentation or the form it must take, only that (somehow) a
reader is supposed to be able to use it to determine the program's
behaviour.  Surely this is unsatisfactory?

It would seem from 1.6 that the documentation of the behaviour can
make reference only to the "program construct", i.e. in the case of 
bitfields the behaviour depends at most on the surrounding 'struct' 
and not on the program as a whole.  Is this a correct interpretation?

Why, given that the behaviour is required to be documented for the 
human reader, does the Standard not require it to be documented for
the program, e.g. by the compiler providing 
  #define INT_BITFIELDS_ARE_SIGNED
or
  #define INT_BITFIELDS_ARE_UNSIGNED
or 
  #define INT_BITFIELDS_CAN_BE_EITHER_SIGNED_OR_UNSIGNED ?