I've been working on interrupt driven half-duplex console communication through one pin, especiially PD1/SWIM on the ICP header, like this:

STM8 device    .      .----o serial TxD "TTL"
               .      |
               .     ---
               .     / \  1N4148
               .     ---
ICP header     .      |
               .      *----o serial RxD "TTL
               .      |
STM8 PD1/SWIM-->>-----*----o ST-LINK SWIM
               .                
NRST----------->>----------o ST-LINK NRST
               .
GND------------>>-----*----o ST-LINK GND
               .      |
................      .----o serial GND 

Code for receive and transmit is fully interrupt driven and buffered. A synchronized timer is used to sample in the middle of a bit time, and it works with any PD port pin (it would work with a different port, too, but that requires using a different external interrupt). Unlike bit-banging the performance impact is negligible (1-2 µs per bit sent or received, well below 2% CPU load at 9600 baud with 100% communication rate). I guess that the code could be used up to 115 kBaud with minor modifications.

If you can live with some garbage on the screen while flashing a new image it isn't necessary to disconnect the serial adapter (I use a cheap CH340) or close the terminal program when transferring a new binary with ICP (I use a cheap ST-Link clone):

ok
���������D�������������i��?��������&�?����
��������r'��n����1���������������
#�����������t�������G������b��҃^�������;�����������
����[����?����v��:d���w�����7�x�O��g�'��3���2�������
������+�_������Z��1����΋/��x���������V���������'�����
�/�������>������=,��
stm8eForth v2.2

The terminal log above comes from this specimen of severe CPU underemployment:

The next complication that needs to be solved is when PD1/SWIM is also used for e.g. LED multiplexing, but I planned to experiment with synchronized LIN-style networks anyway.