We didn't release our version of the m3pi until the August of this year, so we still consider it a relatively new product (you are definitely not "a year too late"). Perhaps some of the older information you see is related to mbed's initial m3pi prototype?
We are not actively involved in further software support for the m3pi, but then again, we are not actively involved in further software support for the 3pi robot, either. The robot is intended as a user-programmable platform, and to that end we have provided an open-source program that turns the 3pi into a serial slave and an m3pi library for communicating with that slave.
For the most part, we consider the m3pi robot an expansion board for the 3pi robot that makes it easy to add a more powerful high-level controller (the mbed) and wireless capabilities to the 3pi, and that's how we support it. This was designed in collaboration with mbed, and we expect most of the mbed support and examples to come from the mbed community. I suspect there aren't a lot of questions on our forum because the mbed forum is the better resource for questions about the mbed part of the m3pi.
Just to be clear, the limits that the 3pi has when it becomes a slave are potentially just limits of our example slave program. The great thing about the 3pi is you can program its microcontroller however you want, so you might be able to overcome some of those limits by customizing the serial slave program. However, limitations involving shared I/O lines, like the 3pi's red LED being on the 3pi's serial transmit line or the 3pi's green LED being on one of the LCD data lines, are not really something you can completely overcome with custom 3pi firmware (the red LED will always be on when the 3pi's UART module is enabled, and the green LED will always flicker when you write to the LCD). Those are simply the result of trying to cram a lot of features into a robot with a limited number of I/O lines.