Why choose a different wording here? Also, the important aspect here is the "end", which commits the current token to the list.

":=" and "==" are added as is, and the parser interprets both dependent on the first character only, i.e. ":" and "=".
The behaviour for these two combinations is unchanged with this patch.

The lexer should not handle ">" and ">=" differently, both are (valid) tokens, and should be returned as such.

Adding e.g. ">=" to the switch statement is not possible, as it works on QChar's.

Because of opening and closing parentheses, but you're right 'end' is the important aspect here.

1. I misunderstood your description as ':=' should become '='.

The lexer should not handle ">" and ">=" differently, both are (valid) tokens, and should be returned as such.

That is what I meant. I was confused by parse() lexing again when encountering a '>'.

Adding e.g. ">=" to the switch statement is not possible, as it works on QChar's.

I don't understand. token is QString. Why not instead of switch (token.at(0).toLatin1())

switch (token) {
case '>'`: comparator = Term::Greater; break;
case '>='`: comparator = Term::GreaterEqual; break;

What am I missing?

I don't understand. token is QString. Why not instead of switch (token.at(0).toLatin1())

switch (token) {
case '>'`: comparator = Term::Greater; break;
case '>='`: comparator = Term::GreaterEqual; break;

What am I missing?

You can only switch on integral statements (ints, chars, ...). With C++11, you can do some constexpr hacks, but your code won't work as is.

You can only switch on integral statements (ints, chars, ...).

Heh? That's surprising![1] Anyway, thanks for the lesson a keep this code as it is now.

[1]
Coming from javascript switch definitely is a "false friend".
Can I become a beef steak?