@danbri @tfrancart @RichardWallis

When creating an extension, it's easy to lock your mind to that domain, and forget that Schema is universal and some day may cover any domain.

The Health-LifeSci extension defined a number of generic prop names with overly specific descriptions, eg http://health-lifesci.schema.org/warning, http://health-lifesci.schema.org/procedure, http://health-lifesci.schema.org/procedureType, and worse of all http://health-lifesci.schema.org/status.
From the prop name, one could never guess the description, so the description is incorrect.
This will force any new extension foo that needs eg status to declare fooStatus, thus proliferating many new props having the same meaning, just different names.

All properties of the http://pending.webschemas.org/Legislation extension have the word legislation in their name. This is better, since all of them are correct in relation to their description. But some of them are overly specific, and with a bit of rethinking they (can) apply to a wider domain:

• legislationDate is very close to schema:dateCreated, imho
• legislationType is about the same as schema:additionalType (but that's a resource and the prop is related to rdf:type; if a mix of resource/text is needed, let's create eg schema:type)
• legislationIdentifier continues the (imho bad) practice of creating subprops of schema:identifier rather than using a resource (like adms:Identifier) indicating the identifier issuer/type
• legislationVersion was happily spared (schema:version being enough), but then legislationDateVersion was created (why not versionDate)?

Reworking either of the two extensions is probably too late. But I think the aspect raised by this issue must be considered for every new extension.
Wikidata's process requires each property to pass independent discussion: since Schema discusses extensions mostly an-block, it's easy to slip into this "silo" thinking.