I can confirm this behavior, but I don't understand much about imperial unity to understand how it should be.

Analyzing the user_string_to_number function, -1'6" is converted to (-1 * 1 + 6 * 0.0833333313) * 0.304800004
I suppose it should be converted to (-(1*1+6*0.0833333313 ))*0.304800004
But I need to do some research to confirm this.

I suppose it should be converted to (-(1*1+6*0.0833333313 ))*0.304800004
But I need to do some research to confirm this.

As an American, I can confirm that movement of -1.5ft is the expected result when entering -1'6".

Writing it out as -1'-6" (as seen below) makes no sense to me.

I am guessing that it is rare to write -1m50cm in metric, and that writing -1.5m would be more common.
So the fact that -1 m 50 cm and -1m50cm both result in -0.5m might be the expected norm in metric, but I suspect that this too is an odd "Blenderism."

In general, I'd suggest to avoid doing anything two clever here, it's fairly likely to back-fire consider users may mix these with Python expressions.
Having said that, both cases look like they could be handled.
For - there could be an implicit conversion from - to -( ... )
The trick would be to do it without breaking statements like
-4 + 0.5 / -1.1

Regarding evaluating
1'6 as 1'6"
this seems simpler, since we could make a rule that ensures the next lower unit type is added if a unit-type was the suffix of the previous number and the next number has none.

Although we might only do this in simple cases, as there are limits to what could be realistically supported.

eg:

1'(4+4) to 1'(4+4)" ? - probably not.

But
1'2.5 to 1'2.5" ... might be reasonable.

For both of these we might want to define a "simple" expression, so if the expression doesn't involve maths / parenthesis, some assumptions can be made.
Although I don't really like this as it means
1'6 might evaluate differently to 2+1'6

Perhaps the same part of the code that replaces ' could do a look-ahead and add the " after the next number.
And try to be robust and support cases like:
10_0.1e-10'9_0.1e+2 to 10_0.1e-10'9_0.1e+2"

Or, we could stop trying to mix Python and unit's as we do now, and instead, only support one or the other.
Only allowing explicit mixing:

{1"2}+{2m3cm} so first we evaluate everything in the {}.
as units. Then pass to Python.

As {...} are used for dictionaries & set's in Python, the chance people want to construct these in a math expression in very low.

In simple cases like 1"2, no need for surrounding by {...}.