I find hopper's comment the most amusing. =P
Anyway, my view of the BLJ and the physics model is this.
Edit: after discussion in the chatrooms it's been determined that the movement system is most likely polar rather than cartesian (angle+velocity rather than x+y+z velocity) and so adjust everything following as necessary.
The game engine (as is most game engines) is built on the principle of rendering textures in planes between vertices. The ground, for example. Everything. Well, enemies are a little different but they're irrelevant here. The point is that the game has models on the positions of planes within the game; it knows where the vertices are to render the graphics textures, and it can reuse that data for the physics engine.
The physics engine, to keep it simple, probably works on one acceleration vector in terms of xaccel, yaccel, and zaccel for 3d space, and one velocity vector in terms of the three dimensions as well. The acceleration vector is quite simply, each frame, added to the velocity vector. There's presumably a detriment on the acceleration vector; friction, Asteron calls it. The velocity vector is also simple, it is simply added to the position value every frame. Before these additions occur, however, the game checks to see if the new position would violate any boundaries - if Mario's cylindrical bounding box would intersect any planes. If it does, it either allows the action by moving Mario vertically until he is in "valid" space (this would account for both stairs and slopes and as Asteron said, probably has a maximum amount) or disallows it by moving Mario as close as possible to the intended velocity vector solution without violating the boundary.
Each set of vertices/each slope has an assigned friction value; this explains why you can walk up the really steep green slope or the cannon slope in BoB but not the pearly marble slope which is much flatter.
I've said that much before.
Issues:
1. Mario doesn't clip through the castle side walls, but he does clip through stuff like the door and the gate.
After giving this issue some thought, I realized that the gate and door have one thing in common - they animate; they exist as programmable changeable objects. What I mean is that they are different in nature than walls; they must be programmable so that when Mario does the right things (gets X number of stars or sets the chain chomp free, for example), they must move out of the way or otherwise cease to exist. The walls do not. This means that they are likely handled by a different section of the engine or are handled by the physics engine differently. This is what allows Mario to pass through them but not the walls. The front of Tick Tock Clock, I guess, falls in the non-wall category. I have yet to explain this problem. Tell me if you know.
edit: To clarify, I think that when the velocity vector intersects with a graphical plane, the game will test to see if moving Mario upwards up to the statically maximum allowed upwards shift (to allow for slopes and stairs) will relieve the boundary violation. When this doesn't happen, the game will simply put Mario as close as he will go before he would have clipped through the object which had intersected along the way of his next velocity-predicted position. In other words, all environmentally rendered objects (textures loaded as planes) will completely block Mario regardless of his speed. The only reason the gate and door does not is because they are handled differently, being animated and conditional; they are more sprites than environment or planes.
2. BLJ but not LJ?
The biggest problem here of course is why BLJ works but not LJ because by knowing that we can explain the nature of the BLJ and use it better. There are I guess a few ways to explain the BLJ.
a. There could be an artificial limit on how fast mario can accelerate which exactly equals his speed at the initial burst of a long jump, but the programmers could have limited this to a positive-only direction. This doesn't make that much sense, unless Mario works on a radial basis (angle and velocity in that angle) rather than a cartesian basis (x, y, z), but it could be. Who knows? edit: On further consideration and discussion, it's actually a given that the control scheme itself is radially based rather than cartesian. The only question left, then, is whether the physics engine itself is based on cartesian or polar coordinates. Zurreco proposes as well a hybrid system, wherein XY movement is determined radially and Z movement is an offset as it would be in cartesian systems. All three systems work in their own right, and Zurreco's hybrid system and the polar system would support this hypothesis.
b. Asteron's hypothesis: the game artificially lifts you at the end of a jump. Unlikely though, you can still longjump in the single frame you have contact with the ground, and plus LJ would still boost on stairs if this were the case.
c. When you BLJ, the angle of attack you come off of is different. When you LJ, you come off more horizontal, grinding you against the ground and causing ground friction before you hit the next step to longjump again. When you BLJ, you only hit the corner of the step and so friction does not occur and you can shoot right up. This would explain why some steps don't seem to work (stairs to basement, front steps), but it's kind of touch and go in that it would be pretty zany for the exact angle to have been programmed by accident to work. But hey, a glitch is a glitch, it wasn't supposed to happen anyway.
d. Somehow, a BLJ isn't considered "finished" when you land. If the game considers that when you LJ again you're on the ground facing forward and it should jump again at the set velocity, then when you BLJ somehow it screws the system up. I haven't thought this one out.
I think c is the most likely option here; because it seems to make the most logical sense and also it supports the only logical explanation for number 3: edit: of course, a is also likely now that we've decided that a radial system is the most logical.
3. Why BLJ doesn't work on slopes.
BLJ must occur where Mario is allowed to jump again but he is not considered "on the ground" and thus a) there is no friction and b) the game doesn't jump with the same velocity but adds on to it. With a slope, Mario pushes into it differently and so he will always register as hitting the ground. So it's a combination of not being the right angle and containing contact to the ground.
All that's the best I can think of right now.
EDIT: For the lazy, this post could be considered long-winded and a pain to read. Heck, I had a headache rereading it. And thus, Zurreco has kindly offered this synopsis:
therefore, the reason that mario can not work around static objects like walls and stairs is because they are not programmed with the ability to not exist. along with this, the BLJ has much more possibile applications than the LJ because the programmers put a velocity cap for mario only in a positive vector: when moving backwards mario is limitless