The current editor has the problem that all additions take the form of replacements. Whenever you have selected a term, if you then choose some new operator, it always replaces the currently selected term. This certainly is clumsy. I know I've been over this ground before, but I'd like to take another stab at the problem.
There are three options here: replacement, insertion, and outsertion. Replacement is what I now have. Insertion would put the new operator inside the current one &emdash; a bad idea in many cases. Outsertion is the interesting possibility. In this case, the new term would enclose the selected term inside of it. I see difficulties arising from various arguement counts for the new operator:
Operator Count = 0
In this case, Outsertion can't work. All operators with arguement counts of zero must be disabled for purposes of outsertion.
Operator Count = 1
This works perfectly. No muss, no fuss.
Operator Count = 2
A little tricky. The old operator must be placed in the first position, but we can always rotate.
Operator Count > 2
Major hassles. What if the user wants to rotate?
Perhaps the solution is to confine outsertion to the fixed operators, excepting the constant operator. Thus, you can always use outsertion on those, but you can't use it with data and functions. That would address most of the cases where the lack of outsertion is a problem.
OK, what's the I/O structure for outsertion? Two approaches: make two clickable areas for each of the icons, a top half and a bottom half. But how would the user know which is which? I'd need a little key beside the operator bar, with the word "Outsert" over the word "Replace".
Alternatively, the user holds down the shift key to outsert, in which case either the cursor changes or the word "Outsert" appears next to the operator bar, replacing the word "Replace". Either way, it looks like I'm going to have some sort of onscreen label.