Wow, Thanks for the reply 
ASHLEY. Unfortunately, given the nature of your question, this must be a long reply, but I will be as brief as I can. I understand fully the limitations on a small developer team and construct 2 is an exceptional product and I am very happy with it. Just saying ! Thank you for you hard work.
(TLDR - the platformer behavior is perfect, for a conventional classically implemented platformer. But... my system is better for what I "need"
Firstly, I understand platforming code can be a bit of a hassle to make. There are so many things to consider and some of the fringe cases can produce glitches that are hard to test for. On the other hand I have already rolled my own collision detection and resolution system a few years ago in XNA – So I do know what I am getting into. I moved to construct 2 due to dev speed and efficiency reasons and occasionally use Unity3d as well.
In the last year I have been working to force box2d into a flexible platformer system, with variable gravity directions and Jump throughs (funny you should mention those) in addition to a custom particle system that allows 10,000 physics based particles to be present in a layout. I have also tied in my own character state management system (keeping track of arriving, leaving, and being currently on ground, walls, ceiling, and other objects, relative movement directions, and collision states) in addition to managing different projection variables. I have a custom input object that can be tied to character controllers or AI.
The reason I chose physics over platformer: 1.) Because it is awesome, and I don't think I have ever seen a "TIGHT" 2d platformer that is fully physics enabled. Basically, my game is a platformer with physics... not a physics platformer, if you understand the nuance I am getting at (imagine mario or meatboy or even sonic but with physics). This makes things like bouncing, moving platforms, explosions, elevators, and more, feel very different than in traditional platformers in a very good way. 2.) Because so many small minded people said it was impossible. As it stands I can emulate the original mario perfectly. In box2d. with physics. Small minds = blown. Objective achieved
Basically, things are going great... I am making a game around this system and I am supposed to be at beta/media ready stage in march... but, as is the norm, I just ran into a large problem in physics (If i want arbitrary changing gravity and slopes in the game)...
In any frame that I change a friction coefficient to a non 0 number that is different from what it was, then the next frame (when the change is actually applied) the velocity of an object is not added to its position (this occurs in vanilla box2d bundled with construct) This lag in a frame is very noticeable. I cannot abide it.
Given the way I handle character movement, I need to change friction of characters on a constant basis. Otherwise they interact quite funny when hitting walls and ceilings, but I can't change a wall or ceilings friction because gravity can be different for different things (meaning a ceiling isn't just a ceiling, it is a floor too).
If I use no friction and handle it myself in context, I need to apply velocity changes based on surface normals. I can create a system in which I know the objects relative gravity, and I know the objects slope based on its family and can work out the normal from there, however this is tedious and it can only allow me to have set angle slopes. It also means I have to make my world with trigger objects that serve to mark slopes. This is also a more inefficient method but necessary because all slopes have to be part of a larger object that has no internal seams (because we can't use chain shapes in construct 2 with box2d)
Being able to simply pull a surface normal from contact information in box2d would be great. Or, if construct 2 has surface normal information... otherwise I have to develop hacks to get at it.
I would use platformer except for lack of control in a few key aspects. Firstly, when traveling on slopes, the object does not store the change in vertical movement as a new dy. Thus if you exit a slope into thin air, the object's perceived y velocity = 0 instantly and seems to "pop" from the slope. I understand what is going on here. I know why it does this (I just read through the behavior). Using surface normals, would be a better way of handling this. From a surface normal you could calculate things like friction and restitution. I want my character to slide meaningfully. I also need the character to base its control on the steepness of the slope. Right now in the platformer behavior, the dx remains the same even when running up a steep slope. (again this makes sense for how it is programmed and is a good classic platformer implementation)... but thats not what I want. Also, The platformer behavior in its general usefulness lacks a few features that are not generally useful but are in certain situations (things like collision forgiveness and collision assumptions based on player intent). Mario 3 has this going for it in spades. The collisions are resolved in respect to what a player would most likely want given input and collision context. Further, the jump through behavior works great but not at weird angles and not with gravity switching... If you stand on a steep edge that cant be climbed but is jump through, if you move in the direction of said platform, you go into it.
Suffice it to say... If I can pull surface normals, then I can fix my system quite easily. I could conceivably make my own system handle physics (I have made a classic platformer behavior using custom movement from within construct 2 events).
If I can't pull surface normal then I need to probably edit box2d behavior and expose that, as that is probably by best bet at this point in time). I have been holding off on including my edits in my project in hopes that by the time I released they would be officially exposed. I don't want to include some edits, then see a release that includes those edits plus more... due to the whole "behavior/same id / too hard to substitute similar behaviors in a giant project".
The only thing that has kept me from simply hard coding my own behavior is that it would kinda eliminate the reasons why I use construct 2 over unity. If I have to do that, unity is better situated for that type of dev process (especially given that I more comfortable in c#).
Does this all make sense?