I'm probably still not following your example completely, but all things considered (and from some recent testing in my own plugin), my best guess is that the rounding-error-values used in this test:

                    if (s < -0.00000022) or (s-1.0) > 0.00000006: continue        # point is outside T

...and the one below there...

                    if (t < -0.00000022) or ((s+t) - 1.0 > 0.00000006): continue    # point is outside T

...are not yet 'loose' enough.  In my own code (C++ code in a Cinema4D plugin) I have changed the above values to:

                    if (s < -0.0001) or (s-1.0) > 0.00001: continue        # point is outside T
                    if (t < -0.0001) or ((s+t) - 1.0 > 0.00001): continue    # point is outside T

...note that the first < test on each line is now reduced to 4 decimal places (instead of eight) and the second > test on each line is reduced to 5 decimal places (instead of eight).

Again, the final numbers may depend on the language (C++ math libraries vs Python vs Poser Python) and the particular scale of the meshes involved, so you basically want to cut the decimal places down until you can get good hits, without starting to pick up false hits (some intersection out in the next polygon somewhere).  The whole idea of that code is to make sure that the intersection point is within the triangle, so we're just trying to account for any rounding error in the math.  If the normal is shooting off in a direction that places the intersection outside the polygon in question, you want the code to reflect that fact.

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.