I'm not sure you interpreted my post correctly.
What I'm simply stating, is that with bad inputs, the system is never going to function as intended. To get rid of bad inputs,
we would very much benefit from documentation to teach us what would be good inputs in order to feed the collision system the best
possible input. If the bugs still persist even with good/checked inputs, which they probably will at times, then at least the modders'
side of the problem is in the clear when debugging.
Don't know which part gave you the wrong idea in that post, but it surely wasn't meant that way
edit:
Real world example, this illegal polygon (marked in red) for example, if this is part of the same instance, and is used for collision detection,
could possible introduce weird behavior at certain angles. Now it is perfectly flat, but what if there is a tiny gap between the edges there,
potentially a big issue, hardly visible:
Same story for what Lazza said, unwelded vertices on the polygons which are facing the track and as for cars, his example
is quite a good one where probably a great deal of the problems with car collisions (converted cars only?) come from.