Apologies if this overlaps with other tickets. I bumped into doc/shacl_maintenance.md via Twitter and have some feedback. Overall thinking about these best practices and design patterns is very important work and I applaud your efforts. I think they are worth generalizing into maybe a wider community, but I'd like to clarify a couple of things first.
1) sh:node cannot be used as an extension/layering mechanism between property shapes. The values of sh:node must be node shapes, so :bf_hasPart_schema_ExhibitionEvent sh:node :bf_hasPart would be ill-formed. sh:node works perfectly fine to form extension hierarchies between node shapes, similar to rdfs:subClassOf between classes but for shapes. There is, unfortunately, no equivalent for property shapes at the moment. Maybe we should have introduced sh:subShapeOf after all.
As a practical alternative, all I can think of is to have the node shapes that collect the relevant properties for your form to have two sh:property pointers, to both :bf_hasPart and :bf_hasPart_schema_ExhibitionEvent, with both having sh:path bf:hasPart but otherwise no explicit relation.
2) Related to this, each property shape requires a sh:path to be well-formed SHACL.
BTW I do like your thinking about alternatives to sh:order, using some hypothetical after/before properties. I am also unclear which pattern would be better. These list-based patterns would however be less extensible, i.e. it's unclear how to insert something in between two properties.
On the distinction between Ontology axioms and SHACL: the decision to call SHACL is validation language was entirely political, because "SHACL is not a modeling language", supposedly. I (and many others) disagree with this though. SHACL is very well a modeling language, and for many use cases arguably a better one than OWL. If you define classes alongside the shapes (e.g. by making the classes also sh:NodeShapes and having sh:property constraints instead of owl:Restrictions), you have basically the same structure as with OWL, yet with validation semantics and not for inferencing. It is IMHO perfectly fine to publish an "ontology" with no OWL axioms and SHACL only. Instead of "ontology" it could be called a "schema" or a "shapes graph".
This also relates to the question about where to draw the line between UI-related properties and validation. I don't see a strict differentiation. For example sh:datatype does define a validation constraint yet it also informs a UI builder about which input widget should be chosen (e.g. a date picker for xsd:date). Just using SHACL for these use cases is perfectly fine.
BTW sh:name and sh:description are very different from rdfs:label and rdfs:comment. Use sh:name to mean the display name of a property - rdfs:label would be the label of the property shape itself. Similar for sh:description vs. rdfs:comment.
I didn't understand your comment about overrides and would be interested to learn more. Constraint definitions in subclasses or sub-shapes (via sh:node) can narrow down constraints, yet not broaden them up.
On outstanding question 6, we have recently added two new properties dash:detailsGraph and dash:detailsEndpoint that can be used to state that the values of a property can be found elsewhere, either in different graphs in the same dataset, or even online via a SPARQL endpoint. I can elaborate if interested. Any such property could be considered for a future edition of SHACL, yet live as a de-facto standard in the meantime.
On question 9, yes! There definitely should be a community effort to talk about widgets.
Apologies if this overlaps with other tickets. I bumped into doc/shacl_maintenance.md via Twitter and have some feedback. Overall thinking about these best practices and design patterns is very important work and I applaud your efforts. I think they are worth generalizing into maybe a wider community, but I'd like to clarify a couple of things first.
1) sh:node cannot be used as an extension/layering mechanism between property shapes. The values of sh:node must be node shapes, so :bf_hasPart_schema_ExhibitionEvent sh:node :bf_hasPart would be ill-formed. sh:node works perfectly fine to form extension hierarchies between node shapes, similar to rdfs:subClassOf between classes but for shapes. There is, unfortunately, no equivalent for property shapes at the moment. Maybe we should have introduced sh:subShapeOf after all.
As a practical alternative, all I can think of is to have the node shapes that collect the relevant properties for your form to have two sh:property pointers, to both :bf_hasPart and :bf_hasPart_schema_ExhibitionEvent, with both having sh:path bf:hasPart but otherwise no explicit relation.
2) Related to this, each property shape requires a sh:path to be well-formed SHACL.
BTW I do like your thinking about alternatives to sh:order, using some hypothetical after/before properties. I am also unclear which pattern would be better. These list-based patterns would however be less extensible, i.e. it's unclear how to insert something in between two properties.
On the distinction between Ontology axioms and SHACL: the decision to call SHACL is validation language was entirely political, because "SHACL is not a modeling language", supposedly. I (and many others) disagree with this though. SHACL is very well a modeling language, and for many use cases arguably a better one than OWL. If you define classes alongside the shapes (e.g. by making the classes also sh:NodeShapes and having sh:property constraints instead of owl:Restrictions), you have basically the same structure as with OWL, yet with validation semantics and not for inferencing. It is IMHO perfectly fine to publish an "ontology" with no OWL axioms and SHACL only. Instead of "ontology" it could be called a "schema" or a "shapes graph".
This also relates to the question about where to draw the line between UI-related properties and validation. I don't see a strict differentiation. For example sh:datatype does define a validation constraint yet it also informs a UI builder about which input widget should be chosen (e.g. a date picker for xsd:date). Just using SHACL for these use cases is perfectly fine.
BTW sh:name and sh:description are very different from rdfs:label and rdfs:comment. Use sh:name to mean the display name of a property - rdfs:label would be the label of the property shape itself. Similar for sh:description vs. rdfs:comment.
I didn't understand your comment about overrides and would be interested to learn more. Constraint definitions in subclasses or sub-shapes (via sh:node) can narrow down constraints, yet not broaden them up.
On outstanding question 6, we have recently added two new properties dash:detailsGraph and dash:detailsEndpoint that can be used to state that the values of a property can be found elsewhere, either in different graphs in the same dataset, or even online via a SPARQL endpoint. I can elaborate if interested. Any such property could be considered for a future edition of SHACL, yet live as a de-facto standard in the meantime.
On question 9, yes! There definitely should be a community effort to talk about widgets.