The good thing is that it is so simple a concept.

All it takes, is for the hw designers to make use of a bit of care, when they do decide which two (or in your case sometimes three) pins that should support the different functions, so that two pins that shares function X does not have another common signal shared. By such a simple design rule, you can normally always find a combination where all needed functions can be used at the same time - just as long as the needs isn't larger than the total number of mappable I/O pins.

A nice thing that can be done when a serial port can be mapped to more than one set of pins is to have the device boot with the serial port on a pin connector as a monitor port. If not "grabbed" by receiving a valid command within a couple of seconds, the program can change the multiplexing and instead map the signals to an internal GPS module. So a 4-UART chip can handle four real ports (say two external, one GPS and one GSM) and still support boot messages and an optional monitor port.

Nothing is as frustrating as trying to use a really complex processor and late in the design realize that some unforseen gotcha makes you unable to use an ethernet interface or a SPI interface. One chip I used had an errata in the USB. The workaround suggested would be to take the external 48MHz for USB and feed to a counter/timer to be able to internall divide by 48 and generate a 1kHz interrupt synchronously with the start-of-frame (SOF). Would work well if dropping the PCMCIA interface. Same chip should be a SPI slave. Would work well if accepting that the SPI slave-select signal required the second ethernet port to be dropped. Stupidities just because a large chip manufacturer decided to give all signals one possible pin, where every device used automatically blocked one or more other devices from being possible to use.

The original 8051 had so few peripherial devices that it wasn't possible to get any collisions. But many modern microcontroller normally have peripherial devices that together sums up to much more than the total amount of pins on the chip. So it's imperative that the chip design optimizes our chances to select any combination of peripherials that doesn't sum up to more than the available pin count. And, of course, does it in a way that a normal developer can understand. And with an attempt to keep the pin allocations reasonably stable when trying to map in one more peripherial function.