The short answer here is that you shouldn’t rely on a student’s entered LaTeX matching a particular form in order to determine correctness. There are just too many ways to enter something equivalent to the correct answer to enumerate them all with string checking.
The two main purposes of the latex source are to (1) display what the student has entered somewhere else in a nicely typeset form, and (2) put the entered math text into the calculator for use in computation.
That’s why it’s not super important to understand “what CL views as the LaTeX” that gets entered: it’s always a form that the system recognizes for typesetting or for use in the calculator (which are basically the same thing). You should pretty much consider those details to be opaque. Almost anything you try to check about raw LaTeX strings will end up biting you.
In this particular case, I think your best move is probably to use the student input inside of a function that returns a 1 at the values you’re interested in, and a 0 otherwise. That way you’ll catch things like |-1+x|=3 or |x-1|=3+12-10+(-2) or whatever.
f = simpleFunction("\\{${input.latex}:1,0\\}")
firstSoln = (f.evaluateAt(-2) = 1)
secondSoln = (f.evaluateAt(4) = 1)
# Add a check to make sure that *everything* isn't a solution.
# This rules out the case that the student entered an identity like `x=x`.
nonSoln = (f.evaluateAt(0) = 0)
correct: (firstSoln and secondSoln and nonSoln)
I just want to note that this kind of solution has some important limitations to keep in mind. For one thing, it’s possible to get false positives: if a student writes something that matches those three checks, it will be marked as correct, and the target equation isn’t the only one that will pass those checks. (Adding a check that 0 isn’t a solution at least rules out one case where the student entered something trivially true.) The other problem is that you end up using an exact equality check in the condition (checking that something is exactly equal to 3). This works in this relatively simple case because everything ends up being integers. But exact equality checks with decimal values are really unreliable because of floating-point rounding error.
Unfortunately, what you really want here are some better parsing tools that we just don’t provide yet. But having use cases like this from actual users wanting to do actual things helps shape our development.