Pretty fun and interesting task. Only have one complaint.
Testcase x + 1 - 9 = -11 seems out of place to me. The description states that all - will be surrounded by spaces. None of the random test cases have negative signs without spaces. The example - x = - 1 suggests that there are always spaces around prefix negative sign. Maybe I'm just being salty because I lost my first try all clear to this, but this testcase does little except cause a small amount of frustration.
If you don't want to remove this testcase, just say in the description that prefix negative sign does not always need to have a space on the right side.

This solution is actually the opposite of clever.
This solution matches all words with length less than 3 or greater than 4 because those words cannot be code or war.
Then, it allows every 3 letter word where the first letter is not w. Then it allows every 3 letter word where the second letter is not a. This continues for every letter in the words war and code.

Here's an explanation of the parts that may be tricky. Will not explain things such as lambda and generator expression. -~i is the same as (i+1). Multiplying an int named n and a list named xs results in a list with the contents of xs repeated n times.

The details of this kata say that the solution can be at most 230 characters long, but the sample tests only require them to be at most 250 characters long. Why is this so?

You can also just use more arguments of the range function, probably faster because it should be implemented in C.

https://docs.codewars.com/references/markdown/extensions/#math-typesetting
This may be of use to you.

It was a coincidence that this was self-describing, but this shows the point pretty well. It works pretty much all the time, domains can sometimes just be annoying.

from math import prod

You don't need to turn that generator expression into a list, you could replace the [] with () to theoretically improve performance.
Or you could just not do any i for i in stuff and just make the second argument the list itself.
You could also pass a 1 as a third argument to functools.reduce to simplify this a little.
Instead of using a lambda, you could import from operator.
Finally, instead of a reduce, you can just use a certain built-in to get the product of the list.

Just realized my solutions based on base conversion don't work because they don't pad left. I've done enough Kumite for today, will deal with it tomorrow.

An interesting edgecase that a fork of this should take care of is the case of coinciding segments, the current solution fails with a division-by-zero.

Didn't realize that was the case, thanks for telling me about it.

The declaration of max should be long max(long, long)

You could save some occurances of std::list<int>::iterator::operator++ if you take it out of the for header, remove the assignment to the return value of std::list<int>::insert, and add and else, but this preserves the ideas of the forked Python solution better.

The point of this was mostly just an excuse for me to have some fun golfing with no fear of undefined behaviour, sorry for not making that very clear.