The two code samples express something very different. In the first example, you express that Sales Orders that you expose via the interface are allSales Orders from your app. The second example expresses that exposed Sales Orders are those for which ?'Invoice created'|'Processing' holds.
As for why you cannot express:
'Set file': command do on $ ?'Invoice created'|'Processing'
You can already express the filtering above in your application model, so it would just be a second way to express something you can already express. In addition, it would mean that you can express command implementation logic in two different places. Currently, you can only do that in an application model.
The provided interface implementation language aims to be a minimal language specifically tailored to mappings between Alan application-conformant data structures and Alan interface-conformant data structures.
With minimal language I refer to the number of concepts that the language supports; the different possible options that you can choose from. What you suggest with the two alternative formulations is about conciseness of the syntax.
As for conciseness: we plan to support the syntax from your last code sample. (In your penultimate code sample, it is unclear where 'Sales Orders' comes from.)
Maybe what is missing here is the explanation for why the syntax currently is the way it is. The fact is that this syntax is prepared for having multiple branches of entries in that collection. For instance, when providing information about ‘Resources’ to a generic planning tool, you could combine ‘Machines’ and ‘Employees’ from your application model. The language will require you to specify unique prefixes and a character to join the keys to make sure the resulting entry id’s are unique.