Question Not Sampled Physics

Hi Unity people,
I was trying the last few days to jam the physics for a space racer like F-Zero / Wip3Out and my mind started cooking.
Having to deal with a collider running at 1000km/h on a track revolving on itself feels really unsafe so I wanted to discuss a completely different approach around physics calculations (I am no science person, I am hear to get opinions or even flame).
I can't wrap my head about the idea having to sample every frame (plus subframes) the space I am playing with if I actually can set up all the rules for it before action takes place. I actually could precalculate what is going to happen in the next frame given an input and don't need to test it and get a correction back, this way I can be in full control of the physical behaviour of what is happening before it happens and not afterwards.

If I know my collision mesh (I have in my mind using a single one - multiple sets would follow different rules and be too complex to think about right now) I could unroll it as a 2D map and navigate a point in a set of coordinates similar to UV coordinates (just virtually seamless), all useful informations for the calculation are stored anyways in the model itself (normals, tangents, weights, colors) and I would be able to calculate the moving patterns between the different triangles.
I could put weights on vertices to declare extra behaviours like walls (i could calculate them also out of a steep normal difference) or even changing the games behaviour, like a button (without further sampling as we know on what triangle we land)

This whole system I don't know the name for reminds me of how navmesh works (with its limitations) and I have to admit it is one of the most reliable systems I faced between the unity tools despite its heavy limitations so I was looking for tips and opinions about the implementation of such a system.


Here a visualization for a racing track


here a visualization for something like a platformer

For sure there are many elements to take care of as how to calculate borders in order to not have the character clip in the middle of walls, or how are slopes properly handled but that would be more of an implementation issue to be solved on the bidimensional linecasting situation and how it behaves based on every face property. But given a lumped world made of triangles I don't understand right now why it's not exploited into character movement calculation.
Another issue could be what happens mid-air when the character has not to be on the surface, if the physics are well calculated then we can always plot a linecast to the next position and stick/bounce on the next intersecting surface, but when floored the character would be stable and is not going to be tested further when not moving.
For sure I am not speaking about a realistic physics engine here, but to a reliable system for game designers and control freaks.

Anyways this doesn't comes easy (it's more of a question why I am not aware of such implementations, or what maybe I'm not understand from actual implementations than how to make it, I am not enough of a mathematics person to entangle such riddle) and found few clues around but not enough to stop me writing this asking for clarification.
Here is a major bottleneck I found: Lower-level way to find NEARBY TRIANGLES on the mesh?
The kind of mesh we used to know would need an overall recalculation to be able to use it this way (baking is an option!)

I would be glad to hear from you about similar systems or why such an idea may be nonsense

Happy developing