Also: The JSON example is nasty. Should IDs then always be strings?
Specs, vs. their implementations, vs. backwards compat. JSON just defines a number type, and neither the grammar nor the spec places limits on it (though the spec does call out exactly this problem). So the JSON is to-spec valid. But implementations have limits as to what they'll decode: JS's is that it decodes to number (a double) by default, and thus, loses precision.
(I feel like this issue is pretty well known, but I suppose it probably bites everyone once.)
JS does have the BigInt type, nowadays. Unfortunately, while the JSON.parse API includes a "reviver" parameter, the way it ends up working means that it can't actually take advantage of BigInt.
> Should IDs then always be strings?
That's a decent-ish solution; as it side-steps the interop issues. String, to me, is not unreasonable for an ID, as you're not going to be doing math on it.
Backward error: the error between the given question, and the question whose right answer is the given answer.
Easier to parse like this: a small forward error means that you give an answer close to the right one.
A small backward error means that the answer you give is the right answer for a nearby question.