The higher baudrate makes the UART module transmit faster, so you have more "spacing" between the bytes, but it seems to me that the rate at which you're transmitting the bytes is still the same. Your timing diagrams are missing total time so its hard to see if this is the case. Don't compare last edge to first edge. Compare the first edges of the the two bytes. Are these still the same?
From what I understand you're asking - you have 2 UARTs at different speeds. You send data into the fast UART, and it sends it out through the slow UART for you, and the problem you have is that you lose data as it's not being sent out fast enough?
Ok. The answer is to use a system called "Store and Forward". This has been used for many years in 10/100 ethernet hubs, where data coming in can be 10 times faster than data going out.
Basically it involves you having a large (typically circular) buffer which is filled by the fast UART, and trickles out of the slow UART.
It only really works if you have a "burst" form of data - i.e., you're not sending data all the time, but sending in packets of chunks with delays in between. This allows the slow UART to catch up and make room in the circular buffer for more data.
In a perfect system you would use some handshaking to tell the fast sender to stop sending for a while. The best is hardware handshaking, where an IO line is used to signal to the sender that it's "Clear To Send" data (CTS). Some chips (PIC32) have this functionality built in with dedicated CTS / RTS pins, but it's simple enough to emulate it on those that don't.
Another alternative is to use software handshaking, also known as XON/XOFF where the PIC24 would send an XOFF character when its buffer is nearing full, and an XON character when it's getting empty again. These levels are known as the "High Water Mark" and "Low Water Mark" respectively, as the whole system can be envisaged as a tank being filled by a large bore pipe, and a small hole in the bottom dripping water out. A valve would shut off the water at the "high water mark" and allow it to flow again at the "low water mark".
Note that the high water mark isn't the same as the buffer being full, only "nearly" full, as software handshaking isn't perfect, and some data can still come in after sending XOF due to any buffers between the sender's software and the receiver's hardware.
Best Answer
Let's annotate your first scope shot. When we do this take note that the lowest order bit of the binary value is transmitted first. Conventional notation in this field is to order the bits in a byte like this:
[Bit 7][Bit 6][Bit 5][Bit 4][Bit 3][Bit 2][Bit 1][Bit 0]
So when I annotate and then evaluate the bit positions are flipped from the positions shown on the annotated scope shots.
The bit pattern represented there is 0b00111001.
That is the same as 0x39.
0x39 is the ASCII code for a '9' character.
Let's do the same for your second scope shot.
Here the bit pattern is represented as 0b00110010.
That is same as 0x32.
0x32 is the ASCII code for the '2' character.