Things that don't work with aliased data:

* Implicit pass-by-const-reference of record types
* Type states, when the object is in a non-final type state.
    - except if the type state is embedded as a variable in the type.

Aliasing within expressions
---------------------------

Forbid potential aliasing/side-effects between subexpressions.

Complex way but accurate way of doing it:

- (1) If a subexpression has a side-effect / modifies state, and
- (2) there's any subexpression that might see/alias that data, and
- (3) the latter subexpression is not guaranteed to always happen before or
  always after the former subexpression,
- then compilation must fail with an error.

Note that (3) means that things like `a <- a + 1` work.

Further analysis:
- (1) is trivial.
- (2) needs further specification, but this could be a simple as "all
  non-local aliasing".
- (3) is complex, see below.

Subexpression execution ordering analysis:

- Assigning each subexpr to the nearest sequence point to the left that
  is in a "group" that is a direct ancestor of the subexpression.
  (note that a function call also is a group, i.e. arguments and the
  function expression itself are evaluated before expressions that depend
  on its return value)
- If at any level, the groups are adjacent (i.e. have an adjacent sequence
  point between them), then the subexpressions always happen in a specific
  order, otherwise they might not do.