Clarify input/output field modifiers of Part 3 collections

When looking at the definitions (and subsections) of:

• https://docs.ogc.org/DRAFTS/21-009.html#_requirement_class_input_fields_modifers
• https://docs.ogc.org/DRAFTS/21-009.html#_requirement_class_output_fields_modifers

All the same terminology, field names (filter, properties, sortBy), and intention for each are reused. This makes it very hard to understand "where" each of those fields are expected.

Furthermore, the only available example (https://docs.ogc.org/DRAFTS/21-009.html#_coastal_erosion_susceptibility_example_workflow) mentions that the input/output modifiers are both used, which doesn't help disambiguate them.

Adding to the ambiguity, the Input Field Modifiers are used to request/filter a certain collection (possibly remote), for which the (output) resulting items/features/tiles/coverages from the search are used as input for the process. On the other hand, (to my understanding), Output Field Modifiers would be used to perform further filtering/sorting/derived-values from a resulting collection from the processing, to be made available for another step, or final workflow result. Since each of these pre/post-filters could be interchanged in some cases, or can be seen (implemented) as sub-processes themselves with inputs/outputs, the operations and applicable requirement classes rapidly become (in their current state) confusing and undistinguishable.

Explicit examples (on their own) demonstrating how Input Field Modifiers and Output Field Modifiers must be submitted in an execution request would help understand the intention.

Something to validate (I'm assuming here):
Are the Output Field Modifiers supposed to be provided under the outputs of the execution request?

Compare the Part 3 Input Field Modifiers and Output Field Modifiers sections in the linked 21-009 draft, then inspect the execution request definition in openapi/schemas/processes-core/execute.yaml. Document explicit standalone execution-request examples for each modifier and clarify where output modifiers belong. Done means the terminology, intent, and request placement are unambiguous.