Thanks for the comments Bruce. Yes, the expansion does appear to try to do arithmetic with a string & that might be a problem with PiecewiseExpand. My real concern is that the results for f2 are actually wrong (execute the "Table" line of code,) - on my computer anyway. Maybe it is because the logic is expanded incorrectly (assumes only Reals maybe??). Curiously, once simplification is applied, these errors seem to be corrected.

Making PiecewiseExpand, Solve, etc, look inside expressions with "==" for non-numerical items opens up a large box of special cases and potential conflicts.

In your example, using (Full)Simplify on the PiecewiseExpand output is probably the easiest workaround. There are things one could do with Hold or HoldForm. There isn't a StringEquals function, but StringMatchQ could be used if keeping strings from being treated as parameters is critical.

StringMatchQ::strse: String or list of strings expected at position 1 in StringMatchQ[y,Yes]. >> StringMatchQ::strse: String or list of strings expected at position 1 in StringMatchQ[x,Yes]. >> StringMatchQ::strse: String or list of strings expected at position 1 in StringMatchQ[x,No]. >>General::stop: Further output of StringMatchQ::strse will be suppressed during this calculation. >>

I see that StringMatchQ makes things work. I'm using a structure like this in a derivative calculation of an ODE being solved using DSolve in a Dynamic environment with sliders, SetterBars, etc. So far I've only gotten NDSolve to give correct numerical results. DSolve doesn't seem to like nested Piecewise equations. I'm ok with the NDSolve version & will work on the more esthetically pleasing version in my spare time.