Conflicting strict requirements for Part 3 collections

In https://docs.ogc.org/DRAFTS/21-009.html, most definitions indicate something in the form or (emphasis mine):

SHALL link to at least one OGC API data access mechanism such as OGC API — Tiles, DGGS, Coverages, Features, EDR, Maps

This implies that providing a collection as, for example, ONLY an OGC API Features (or STAC) endpoint would be valid. However, that API does not necessarily handle all sub-requirements for input field modifiers. For example, filter and sortBy could be handled relatively easily in this case, but not properties, since it involves a more advanced set of capabilities to compute derived values.

Similarly, the Collection Output has prerequisites that enforce support of all OGC API data access mechanisms:

https://docs.ogc.org/DRAFTS/21-009.html#_requirement_class_collection_output

http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core
http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections
http://www.opengis.net/spec/ogcapi-tiles-1/1.0/conf/geodata-tilesets
http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/core
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/core
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-scaling
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-subset
http://www.opengis.net/spec/ogcapi-coverages-1/0.0/conf/coverage-rangesubset
http://www.opengis.net/spec/ogcapi-dggs-1/0.0/conf/data-retrieval
http://www.opengis.net/spec/ogcapi-dggs-1/0.0/conf/zone-query
http://www.opengis.net/spec/ogcapi-edr-1/1.0/conf/core
http://www.opengis.net/spec/ogcapi-edr-1/1.0/conf/collections
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/core
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/spatial-subset
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/datetime
http://www.opengis.net/spec/ogcapi-maps-1/0.0/conf/scaling

Another example is the Nested Processes, which requires:
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/nested-processes

http://www.opengis.net/spec/ogcapi-processes-1/1.0/req/core
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/input-fields-modifiers
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/output-fields-modifiers
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/collection-input
http://www.opengis.net/spec/ogcapi-processes-3/0.0/req/remote-collections

However, if a nested process happens to return a GeoTiff, for example, and the parent process in the chain receiving it supports this media-type, there is no reason to go through Collection Input, Remote Collection, or apply any Input/Output Fields Modifiers. A Nested Process definition would be valid on its own. Although these capabilities could be combined simultaneously with a nested process that returns a collection output applied for a particular processing chain, they are not required.

I believe it would much more beneficial for the adoption of these capabilities to reduce the "combined set" of requirements. They define much more granular combinations. This would allow implementers to gradually add more support, without having to implement everything all at once, especially that not all capabilities are necessarily desired. It would also better align with the mention of "at least one" OGC API data access mechanism that must be supported, not all of them.

Start by reading the Part 3 draft, especially the Collection Output, Nested Processes, Collection Input, and Remote Collections requirements linked in the issue. Compare their combined conformance requirements with the stated “at least one” access-mechanism wording; done means the draft clearly defines granular, internally consistent capability combinations.