I am not sure that nontrivial field initialization contributes /necessary/
complexity.

Having said that, the paradigm for field initialization seems wrong to me.
It imposes arbitrary limitations which I believe to be simple to overcome in an
alternative design suggested at the end of this post.

But first, the problems with the current approach:

* It arbitrarily limits the kinds of computations that can be performed
   during initialization of a field.  For example, one cannot reuse
   intermediate results needed for more than one field.  Each field has to be
   recomputed from scratch from the inputs.

* It has the wrong granularity.  A common use case it cannot handle
   is a consistency check of the arguments before computing
   the individual fields.

   A related use case is where the constructor has optional arguments,
   where the number of arguments need to be determined before computing the
   fields.

* A record type definition declares an implicit constructor procedure.
   However, the actual body of the procedure is interspersed with other
   syntactic elements, which seems gratuitously complex to me.

* The design requires record declarations to be a new binding form.
   Apart from the lack of economy this entails, this binding form has
   an somewhat unusual, and therefore guaranteed to be confusing to many,
   scoping rule.

* There seems to be a more powerful and simpler alternative:

Alternative Suggestion:

  Instead of having a separate <init expression> for each field, one could
  simply have an <expression> for the constructor, which should evaluate to a
  procedure that returns the computed fields (using VALUES, for example).

  This would solve all the above problems.  The overall gain in power and
  simplicity would be, in my view, significant.

Regards
Andre