TPS is supposed to be exact at GCP, and interpolate between them. That said, it looks from this report like there might be a numerical stability issue. There are 2 solvers for the TPS transformer: a built-in that does matrix inversion "at hand" using Gauss-Jordan elimination method (the one that is taught at school if I remember well -:) ), and another one that uses the armadillo library that is faster and relates underneath on well proven numerical computation libraries (blas/lapack). I don't think osgeo4w builds use armadillo (actually I don't see anything in the nmake.opt related to armadillo).
That said, I see that the Gauss-Jordan implementation usd uses the "partial pivonting" mentionned in
https://en.wikipedia.org/wiki/Pivot_element#Partial_and_complete_pivoting so this should normally account for most numerical stabilities issues.
So either the user is rather unlikely and has encountered a case where numerical instability occur, either his test/GCPs are wrong.
And I wouldn't have anticipated that numerical stabilities issues have such a north-to-south pattern, but perhaps...