That solves the main issue that I had with the previous resolution.
I am not sure that the "remove any attributes other than readonly"
is any simpler or better than "remove the export attribute (if...)" as
that one is the only attribute other than readonly that exists.
The proposed text presumes that if other attributes are someday
added to posix, that unset will remove them as well.
I know that many of you think that new attributes just means things
like "integer" or "array" as that's what the extensions in most shells
have been - and it is natural for unset to clear an attribute like that.
But it is also possible to add new attributes more like "readonly"
which unset does not clear - the NetBSD shell has a "unexportable"
attribute, that can be set to prevent variables being exported.
That one isn't cleared by unset, so the "remove any attributes
other than readonly" won't be satisfied by the NetBSD sh, though
"remove the export attribute" would be.
[ aside: FYI: unseportable prevents "export" and the effects
of set -a, it does not prevent "VAR=foo command" type exports.]
Of course a conformance test would not notice that, as it would
never set the unexportable attribute (such a thing not existing in
POSIX) but users reading the standard, and comparing what
the shell does with what the text states will happen might get
confused.
A similar attribute I have considered would me "modifiable" - that
is, an attribute to prevent readonly being applied to a variable.
This is because having some sh variables made readonly would
cause lots of scripts (and sh functionality) to break, just consider
the effects of
readonly OPTIND
kre
