After the discussion in the other thread, I did a little bit of research with regards to other languages and how they handle this and their rationale.
So it seems that there are two competing definitions of mod. Let's consider x = a mod m.
The number theoretic model says that the mod operation should return the congruence class as represented by the smalles positive number. I.e. x is element of [0..m-1] such that there is a k element Z such that a = k*m + x. This is how it is employed by for example Python.
The other definition of mod is the remainder of the definition, which is basically defined together with the integer divide operation. Here the definition of mod is x, k element N such that a = k*m + x where k is a div m. This is employed this way in languages like C++. The rationale behind this is simple, div and mod should be complementary implementations, i.e. if you have x = a mod m and y = a div m, you can reconstruct a by just calculating y*m+a.
Both have their use cases. The GMP for example implements both, mpz_tdiv_qr(q, r, n, d) stands for trunk div quotient and remainder and returns a quotient and remainder such that q rounds to 0 and q*d+r = n, while mpz_mod(r, n, d) returns an r such that r = n mod d and r is in [0..d-1].
So long story short, the default implementation used by the FPC is basically what is commonly referred to as the remainder and is complementary to the integer division such that (a div d)*d + (a mod d) = a, and is also used this way in for example C and C++, while with {$ModeSwitch isomod} the mod operation does not compute the remainder, but the congruence class as commonly used in discrete maths/number theory