hello past self, nice to meet you

Oh, the things one runs across as one sifts carefully through every
usage of the MODULE and FINAL flags in trunk because of the subtle
non-local effects which arise from decoupling them. If only someone had
anticipated this eventuality... (Ow, I broke my arm trying to reach that
spot on my back.)

Setup line: "It's not relevant whether this example poses any issues."
Oh sure, that's such 2010 thinking. NOW it's relevant.

commit 067942feb951ce655539423eeba53251160ac45d
Author: extempore
Date: Wed Oct 13 04:48:20 2010 +0000

/** ISSUE #2: Implicit flag relationships must be made explicit.
*
* For instance, every time the MODULE flag is set, the FINAL flag is
* set along with it:
*
.setFlag(FINAL | MODULE | PACKAGE | JAVA)
.setFlag(FINAL | MODULE | PACKAGE | JAVA).setInfo(rootLoader)
new ModuleSymbol(this, pos, name).setFlag(MODULE | FINAL)
new ModuleSymbol(this, pos, name).setFlag(MODULE | FINAL)
val m = new ModuleSymbol(this, pos, name).setFlag(MODULE | FINAL)
setFlag(module.getFlag(ModuleToClassFlags) | MODULE | FINAL)
sourceModule.flags = MODULE | FINAL

* However the same is not true of when the MODULE flag is cleared:

sym.resetFlag(MODULE)
.setFlag(sym.flags | STABLE).resetFlag(MODULE)
sym.resetFlag(MODULE | FINAL | CASE)

* It's not relevant whether this example poses any issues: we must
* not tolerate these uncertainties. If the flags are to move together
* then both setting and clearing have to be encapsulated. If there
* is a useful and used distinction between the various permutations
* of on and off, then it must be documented. It's the only way!
*/