>This works:

>PRIMES=2 3 5 7
>NUMBERS=1 2 3 4 5 6 7 8 9 10
>foo:
>	echo ${NUMBERS:@n@$n is ${PRIMES:M$n:C/..*/prime/W:C/^$/not prime/W},@}

For this specific case, but not sure I like it as a general solution ;-)

>> 2. Make cond.c not require a variable reference for string
>>    comparisons.  This would allow:
>> 
>>    ${NUMBERS:@n@${("${PRIMES:M$n}" == ""):?$n:}@}
>> 
>>    to work.

>This seems like a good idea.

This is the one I'm currently implementing.
It seems the most generally useful.

>> 3. Provide a means of saying "don't" expand yet, so that ${PRIMES:M$n}
>>    could be passed down to cond.c - or perhaps make that implicit if
>>    :? is present.

>Perhaps make backslashes work in ${\${PRIMES:M\$n} == "":?yes:no}

Yes I thought of that - but couldn't imagine how many things it might break.

>I don't like the idea of making the delayed expansion implicitly
>depend on something else in the expression.

Me either - just throwing ideas around.

>> 4. Make:
>> 
>>    ${PRIMES:M$n:?:$n}
>> 
>>    work as expected?  Ie. if ${PRIMES:M$n} is empty, then :? should
>>    eval false.

>This also seems reasonable.

Yes, mean to check in gdb why it doesn't.  empty(${PRIMES:M$n}) doesn't
work becuase the cond code sees either "empty()" or "empty(2)" etc,
both of which are true - unless you happen to have a variable 2 defined.

--sjg