This problem appears to come up too often so something must be wrong.

I put a "crosswired" cable between COM1 and COM2 on my PC, run FM (COM1) and a terminal program (COM2), setting a long timeout in FM. From the terminal, I "faked" the answers to FM. This is the record of received data - I inserted CRLFs between the "hex" records and comments:

UU autobauding
:0100000216E7  setting Xtal to 22MHz (I set 22 in FM)
:020000050003F6  reading FX2 bit, I answered 00
:020000050700F2  reading security bits, I answered 00
:030000030600FFF5  program status byte to FFh
:0100000307F5  full chip erase*
:10000000759852758921758DF4D28E75C8207581C9  program first 16 bytes of data
:1000100007C0813099FDC2998508993099FDC29930  program second 16 bytes of data
etc. programming continues for the whole file

The documents do not specify the "default values", but they say that In fact, after performing full chip erase, boot vector (and status byte, too) are 00. FM starts programming the data immediately full chip erase, so the boot vector remains 00 until the whole file is programmed, when FM checks the current state of boot vector and sets it appropriately. If somebody interrupts the data programming e.g. by resetting the chip, there is no way to get into the bootloader again, except using parallel programming.

From this, three consequences follow:
1. Philips should be more specific for the full chip erase command (and/or the ROM bootloader should not have had this suicidal behaviour, rather it should reprogram boot vector automatically after performing full chip erase)
2. FM should reprogram boot vector immediately after performing full chip erase
3. FM users should better use Erase Blocks Used by Hex File, rather than Erase all Flash

Jan Waclawek