https://tools.ietf.org/html/rfc7217 says:

  The resulting Interface Identifier SHOULD be compared against the
  reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
  and against those Interface Identifiers already employed in an
  address of the same network interface and the same network
  prefix.  In the event that an unacceptable identifier has been
  generated, this situation SHOULD be handled in the same way as
  the case of duplicate addresses (see Section 6).

In case of conflict, this suggests to create a new address incrementing
the DAD counter, etc. Don't do that. If we generate an address of the
reserved region, just rehash it right away. Note that the actual address
anyway appears random, so this re-hashing is just as good as incrementing
the DAD counter and going through the entire process again.

Note that now we no longer generate certain addresses like we did
previously. But realize that we now merely reject (1 + 16777216 + 128)
addresses out of 2^64. So, the likelyhood of of a user accidentally
generating an address that is suddenly rejected is in the order of
10e-13 (1 / 1,099,503,173,697). Which is not astronomically, but still
extreeeemely unlikely.

Also, the whole process is anyway build on the idea that somebody else
might generate conflicting addresses (DAD). It means, there was always
the extremely tiny chance that the address you generated last time is
suddenly taken by somebody else. So, this change appears to a user
like these reserved addresses are now claimed by another (non existing)
host and a different address gets generated -- business as usual, as
far as SLAAC is concerned.