I'm still working on the spec, and have been reading it over with
a much more critical eye.  Amazing what a close reading reveals.

Section 3.3.4 says "Any write sessions to the PUCK should be
proceeded (sic) by the PUCKEM command".  (Should be "preceeded").

So my proposal to add a flag that says "you must preceed PUCKWM with
PUCKEM" is superfluous.  If we also explicitly call out that
"any write sessions to the PUCK should be preceeded by the PUCKEM
command and followed by the PUCKFM command", then both proposed flags
would be unnecessary (the other one saying you MUST do a PUCKFM).

A couple of suggestions, though.  This is kind of buried in the doc
under the PUCKEM command.  There really should be a separate section
of the doc specifying how to do a "write session", with the above verbiage
in there.  And it should specify what a "write session" is.  I.e., a
"write session" begins with a PUCKEM, includes any number of PUCKWMs
(and presumably PUCKSA and PUCKGA to manipulate the address pointer?),
and ends with a PUCKFM.  That would nail down what is and isn't acceptable
in terms of the sequence of operations.

However, this forces the PUCK implemention to always erase all of memory
before doing a write.  I can imagine that it could be nice to be able
to implement PUCKWM without PUCKEM or PUCKFM.  Many implementations would
have the capability to directly write on arbitrary boundaries, and it would
be nice to support them.  Perhaps a future extension?