The discussion in the ad hoc today made me uncomfortable.
I think it's not a good idea for TOSCA to specify DSLs that model runtime algorithms. Doing so dictates the behavior of orchestrators and puts implementations in a difficult place: if they do not wish to support this feature (I definitely wouldn't, because it's extremely limited) they would have to be non-compliant. We can make it an optional feature (like we are suggesting, perhaps, to do with workflows), but ... I think we would be creating a complicated matrix of compatibility, which would be unfortunate.
I think there is a much better solution: model your not selection algorithm behavior using TOSCA data types. Do you like the proposed DSL? Great, I don't think we need to or should change TOSCA's syntax to support it.
Attached is a comprehensive example I created that mimics the proposed filter DSL using data types. It uses TOSCA 1.3 with no modification. It is heavily annotated with descriptions and comments.
You'll notice some subtle points where it is actually an improvement over the DSL. For example, specifying how many nodes you want selected, and what to do in case not enough nodes are available (do you want to provision the extra nodes?). My point here is also to show that the proposed DSL is a "lower common denominator" that is already insufficient even for the most trivial real world use cases.