I'd like to avoid any work or even discussion about refactoring the core here because:

- As I noted above, I don't want to get side-tracked. I have the resources to work on the assumptions in my free time, but not to work on the assumptions and the core.

- Unlike the assumptions, I don't feel that I have an idea of what *should* be done in the core. For the assumptions, I feel I have a clear vision on how to fix them, or at least I am on the right path. For the core, I still don't feel like I have seen the right answer, so any work on it would be stuck mostly in discussion mode.

Of course, if you want to have that discussion, feel free to bring it up on the mailing list. But I won't be spending resources implementing things in it at this point in time.

- As I noted, for Add and Mul, this issue isn't actually a real one, because the above representation won't work, since they are multi-arg. In fact, I haven't yet thought of any instances where it does become an issue, because every example I can think of would have to represented using some kind of Any or All constructs (which I still haven't completely thought through, so I'm still vague on how they would work exactly). 

- Assuming a case does come up, we'll just fall back to the method I am currently using. I think we'll need to keep it, or something like it around for API purposes, just to ensure we don't limit what the handler system can do too much.

You're right about compromises. I'll try to avoid doing something unless it seems like it would be a good idea going forward. If there's something I'd like to do but it can't be done yet (like Q.positive + Q.positive), I can just fall back to the way that does work (like using a `lambda` or whatever) and put a TODO in the code.