A better description of your test analysis, which may help explain things, is
- hserout is FLOATING while the pause occurs
- hserout is low after hsersetup has occurred
- hserout outputs a FLOATING->FLOATING->0 pulse (something less than 1ms as 'scoped) at a time consistent with hsersetup occuring
After a reset the pin is not driven, it is floating (input status) until the hsersetup command occurs. Therefore the state of the 'txd' signal sent to the computer is completely unknown, it is a floating , non-driven, signal.
After a download the PICAXE is 'reset' (using the assembler code 'reset' command). This is similar, but not completely identical, to a power on reset - in either case the PICAXE chips runs exactly the same firmware code when the program restarts. the hsersetup command simply enables the hardware USART port - all high/lows themselves etc. are done by the internal PIC hardware, not the PICAXE firmware It might well be the USART hardware pulses itself in this situation, we can look into that, but the PICAXE firmware can't change that if it is the case.
You could try a 'low c.6' command at the start of the program, or a 10k tie-down resistor on the output to stop the floating. However the bottom line is that any serial system, as indicated by others above, should always be tolerant of some garbage data during initialisation.