I've been trying to make a proper platformer with slopes for *ages*, and a while back I remembered seeing NSMB with collision lines, so I thought I could learn from that!
So I've been playing NSMB with the collision info hack, and I've been learning stuff about it by playing it with the lines on, but there are a few things that I still think don't make sense.

1.) Is the collision system reactive or proactive? That is to say: does Mario move, and then check if he's landed inside of a collision using the sensors, or does Mario heck for collisions *while* moving?

2.) Speaking of the sensors, how exactly do they work? I think this is the real meat of my question. It seems obvious when Mario is standing on flat solid ground: it just checks whether it is inside of a block, like this:

In these images I drew my own approximation of the tile borders. Plus, I drew dark blue where the collision occurs, and green for the middle of the bottom collision (for later).
This whole system seems to be overthrown by sloped tiles, however, like in the following image:

In this image, it seems that, despite the sensor being inside the collision, here only the middle counts as collisions! Okay, so far so good: Regular tiles, all of the sensor. Sloped tiles, middle of the sensor. I'm assuming this goes for both the bottom collisions, as well as the collisions on the side.
But then, you got the spots where regular tiles go into sloped tiles, like here:

(excuse the misalignment of the middle with the tile borders, I think I misdrew something but I think I'm making my point clear anyways)
Here, you can see that the dark blue part of Mario is also inside of a regular tile, yet mario is phasing through it no problem! And what if the side collision touches one of the full tiles? It ignores it as well, right? Even though it's a full block that it wouldn't otherwise ignore!
And last, but not least, Mario can still stand on regular tiles, even though he would pass through them in the other case! Look at this image:
Here we see Mario standing on a tile, even though he is inside of the sloped tile above it!

The truth is I've been aware of these kinds of edge cases for a long time, and I was secretly hoping that studying these things would help me show how exactly it works. I've tried explicitly checking for cases like these in the past, and while it does work, it completely falls apart when you start throwing steeper slopes, collisions with objects other than tiles, bigger player sizes, or rotating gravity in the mix. And this game has all these things!
So I would greatly appreciate it if anyone were to point me in the right direction on either how exactly this collision system works, or how to reverse-engineer this stuff for myself.
Thanks in advance!

1) NSMB uses a reactive system. Actors change their position and after that the collision manager (the thing that controls the sensor) moves them to where they can or should be.

2) The tiles where slopes go into flat ground actually aren't solid tiles. They have a special tile behavior. Basically a "flat slope" that always pushes you on top. If you didn't place a tile with that special behavior Mario wouldn't go up because the lower sensor hits it from the side as you said. Later NSMB games after NSBMDS don't require that special "flat slope" tile anymore. No idea how they solve it there though.
_________________________
GitHub - Kuribo64 - YouTube

Whoa that's interesting! So there is a central class that moves everything outside of collisions, instead of every actor doing it separately?!

And that is a really clever solution! It makes me wonder how it works with Mega Mario though, because I'm assuming the side sensor would have a bigger overlap than one tile there. I'll try it out with the collision info hack again though to see if I'm wrong on that one!

EDIT: Oh wait, is that the reason there's only gentle slopes on the first level?! I'll try to find a steep slope in a Mega Mushroom level but if that's what it is, that's fascinating!

Now that I know NSMBWii does it without having to make compromises in the levels themselves, I would *love* to know how NSMBWii does it... The search continues, I guess.

I think I wasn't specific enough.

Every actor that uses sensors has a member class that controls the sensors: CollisionMgr.

The actors basically do this in onExecute:
- Change position
- this->collisionMgr.execute()

The latter thing then places the parent actor where it can be if it is inside a block, slope, etc.

There isn't a central class that handles this.
_________________________
GitHub - Kuribo64 - YouTube

Ah okay, that makes a little bit more sense! So my original suspicions were correct. Thank you so much!