>     John and I very strongly desire what I'm now calling the 'convention
>     key, you refuse to explain your allergy to having one mandated key,
>     why it ... /ruins???/ your vision of the SRFI.
>
> I think he _has_ explained it, and I'm willing to put in more time on
> it.  It's not a blocker really, since the use of 'convention is only,
> er, a convention.  It's just a question of how hard SRFI 198 pushes it,
> which is a tiny change to the SRFI and a tiny change to the
> implementation to check it or not at creation time.

Thanks. Agree:

- What if an object conforms to more than one convention?

- What if it doesn't conform to any?

I view the properties like a language that should let people say vague
things in addition to precisely contextualized things. Precise claims
should sound precise, vague claims should sound vague.

If we have 'code but not 'set, that sound as vague as it is. If we have
both 'code and 'set, that sounds as precise as it is. I don't see a
problem if there is no mandatory coupling.

I'd prefer to amass a set of properties where each property is defined
so robustly that it is in effect its own convention, or forms an obvious
convention together with a few other properties without us having to
explicitly divide large numbers of properties into groups. E.g. the
triplet of 'set and 'code and 'name forms a little island of related
properties, but that island doesn't need to put restrictions on other
unrelated or only loosely related properties.

I agree with Harold that being able to ask questions like "did this
error come from libsodium?" is very important. However, an '(origin
libsodium) property, independent of other properties, ought to do the
job as well as a master key. As usual, the name is up for debate.