Even if your baud clocks are perfectly matched if the delay between characters is close to one bit time (maybe even up to 11 bit times) the pattern really is ambiguous.
No, it's really not. The reception of a byte begins with the falling edge of the "start bit" from the idle state. The internal logic then skips the rest if the start bit, reads the appropriate number of data and parity bits into a shift registers and it's DONE. The one-bit time of "stop-bit" that you're worried about doesn't even need to be checked for validity, and can probably be SHORTER than a full bit length, just so long as the internal logic has time to see the next edge transition. Most uarts sample the bitstreams at 16x the bit clock...
Of course, this does mean that you have to reliably notice the "idle state" to start with, and an "idle" time of greater than one byte time should pretty much guarantee that, but the all nulls bit pattern isn't any worse than many other character patterns (historically a string of capital U's is particularly tough. IIRC, it's a square wave...) Trying to tap into an existing continuous async data stream is pretty tough; you CAN'T reliably detect the stop/start bit combination without having an idle state exceeding one byte time. But zeros are no worse a problem than other patterns (and perhaps less, since there is only one bit that could possibly be the stop bit...) (On transmit, a uart includes the stop bit(s) as part of the transmit shift register, so there should never be a "too short" stop bit.)
(You can of course imagine a BROKEN UART, or more likely a broken implementation of a SW bit-banged UART, that doesn't transmit a proper stop bit, but that would be merely BROKEN, not a degenerate case of async communications behavior.)
(Consider old-fashioned protocols like X/Y/ZModem that happily transmitted binary files all around the pre-internet...)
All that said, I don't know that it helps the original poster any.