Clarify media-type and format negotiation of Part 3 collections

Given a process executed with Part 3 collection (rather than value or href), the data passed as input or produced as output of the process seems to imply that it will be a GeoJSON FeatureCollection, or an equivalent representation such as STAC Collection or GML.

Given this implication, can it be assumed that only process descriptions that explicitly support format: geojson-feature-collection (or alternate "collection-like" formats) can safely employ the collection input/output? A process expecting, for example, a GeoTiff would be automatically invalid if a collection was specified?

Given that a collection can also imply an array of "whatever item the collection contains", would a process expecting an input array of GeoTiff be a valid candidate for a collection with a STAC Collection that happens to contain those GeoJSON Items with STAC Assets employing GeoTiff media-types? Would this process still need to indicate format: geojson-feature-collection support explicitly (IMO, yes) to avoid ambiguity regarding how those GeoTiff should be parsed?

Are there other use-cases not mentioned above to consider?

The Part 3 document needs to clarify these considerations such that expected behaviors by implementations can somewhat "agree" and improve chances of interoperability. The versatility of collection, although useful in some cases, somewhat acts as a double-edged sword when describing and execution processes, since processing intensions can become too abstract.

Start by reading the Part 3 collection definitions and its sections on media-type and format negotiation. Compare the stated collection, GeoJSON, STAC, GML, and GeoTIFF cases with existing normative requirements; done means the document clearly defines which combinations are valid and how implementations should interpret them.