Platforming and Physics
These edge cases are numerous. Good fun platformers do not behave in any kind of physically-accurate manner, and the control and behavior that players expect after years of "perfect" platformers like Mario are incredibly difficult to implement with general techniques like you get with Box2D or other physics engines. Most good platformers do not use any kind of generic physics or collision response in their player controllers.
Generate Hulls
Regarding your specific question, the best solution is to stop using boxes as your ground. Use a series of connected line segments (a hull). That allows the collision detection engine to only focus on the actually walkable surfaces and not look at the "fake" edge that exists between A-B and B-C. That is what Box2D does, in fact. The shapes are used to generate the outward surfaces, which are linked together to form a hull.
You need this even in tile-based games, or in situations where you have two AABB objects next to other acting as the floor. The collision engine will pick up those vertical edges and cause the player to catch on them. There are hacks that can help, but not eliminate the problem. The solution is to just have a single line segment representing the surface rather than a full 2D box.
You can generate the hulls in the generic case by clipping the polygons against each other and joining the clip points into an edge list.
Sloping Surfaces
Since your example includes a slope and you're mentioning restitution and other physical properties, I'll point out a few other problems you're going to notice soon, which further illustrates why generic collision detection and response does not work well for platformers. First, try standing on the angled platform, jump up, and then land. You will likely notice that the character will "slide" a bit when landing. The problem is that the contact normal you're generating is usually going to be pointing out from the angled surface. Then, when resolving the collision, the player is pushed out in that direction. Even though the character was fall straight down, he'll be pushed up and a little to the right when landing, resulting in the slide. This can be hacked by taking the relative velocities into account, or by just hacking it so that the contact normals for static surfaces are always snapped to be axis-aligned.
The second problem you're going to notice, which is much harder to fix, is what happens when you try to run quickly down a ramp. The player is going to "hop" down the ramp. This is very visible even in most AAA games today. It not only looks silly, but if your game requires the player to be footed on the ground to jump, it makes it difficult to run down a ramp and jump halfway down, because the player is only contacting the ramp during a small portion of the time spent going down it. A simpler fix is to simply do some ray casts when the player moves, and snap the player position down to the nearest surface (if it's very close to the player) if the player is not jumping and was previously on the ground.
You may also find that the player launches into the air when running up a ramp if you try to model velocity, friction, and restitution on the player as if he were a normal rigid body. The player's movement should be constrained to horizontal movement unless falling/jumping. Of course, if you play older golden-age platformers, you may notice that the player's horizontal velocity is often constant between horizontal and sloped surfaces. This needs to be taken into account when walking up/down slopes as well.
There's going to be a number of other odd corner cases you'll eventually run into, too. If you're trying to make a good platformer, it's really just best to implement a platformer player controller separate from physics and hardcode the movement and control behavior you want, rather than relying on generic physics and collision response algorithm.
