I have just noticed this very interesting thread. Let me just add a couple of comments:
- schemes where trying o avoid "U" by protocol might not work. In particular, the proposed "low nibble only, high always zero" when transmitting continously 0f 0f... produces the same pattern as "U",just 5x slower, so the bootloader would get activated. Although some very elaborated scheme to avoid this may exist, I would not go this way.

- by the way, a bootoader activated by receiving a character within a (not too well, btw.) given time, is not the best idea, possibly leading to uncertainty in the bootloader activation (as in this case). The chip has only one serial port and it is the way to "outside world" in most of applications. It is very restrictive to try to avoid false bootloader activation. And - I am surprised, why Philips did not implement any one of these - the bootloader activation may be easily bound to events not commonly occuring during operation, e.g. a very long break (~100ms, or user adjustable time), or pulldown on a user selectable pin (e.g. Tx or any other), and these can all be implemented as options. And of course, the direction turning pin (again, user selectable, why not?) can be also present as an option. I would also propose an alternative bootloader working e.g. on SPI.
A modified bootloader would be also the best solution to the present problem.

- I see no reason why automatic turning of direction would not work properly with 460kbps or even 10Mbps, of course with properly designed monostable flipflop (or a small microcontroller fulfilling the same task) rather than just a "capacitor"; both at the master (usually a PC) and slave (often a mcu). This solution has two drawbacks, both not posing a problem in typical RS485 applications: working not well with varying baudrate and turning the direction (worst case 1 byte time) late. (I would not use turning to transmit only during zero bits, as suggested in the previous posting).

- when upgrading a 485-networked device, I would not resort to the original bootloader, as this may cause problems when misinterpreted by the other connected devices. Also it needs resetting the device, i.e. somebody must go to it, which is almost equivalent to going to it with a laptop and connecting to a custom RS232 header etc.
To employ the existing infrastructure (long cables) and make the upgrade comfortably centrally and make it as robust as possible, the existing protocol which is implemented on RS485 should be employed, with a custom bootloader as a part of the application, possibly utilising the IAP features of the P89V51RD2. The added bonus is that there is no more direction turning issue, and you may also make it encrypted and device serial number-dependent for added IP protection; drawback is that you have to write the central (PC) part of it.

Jan Waclawek