I have been using a custom .hex file which only has UART3 enabled,
as I want to get as many GPIO as possible. Testing using PA1,
PA2 and PA3 things worked OK.

However, when I initialised most of the remaining GPIO to output low
avoiding the following pins:

PA0   WAKEUP
PA11  USB_DM
PA12  USB_DP 
PB3   SPIx_CLK
PB4   SPIx_MISO
PB8   UART3
PB9   UART3
PC14  OSC32_IN
PC15  OSC32_OUT
PD6   SPIx_CS
PD7   SPIx_MOSI
PE3   LED_D1

(SPIx is for the on-board flash)

and tried to run rshell on the UART3 pins it would not boot-up.

So, next I tried to reflash the custom .hex file and now STM32Cube
Programmer would not talk to the board.

OK, let's try a .dfu file. Using a file from here:
https://github.com/jkorte-dev/micropython-board-STM32H723VGT6/blob/main/firmware/firmware.dfu
the board springs back into life.

Why did I lose the ST-Link capability? Was setting one of the other GPIO,
not listed above, to output low having an effect?

Before I "kill" more on this dev board my main question is:

if you have set a port to an alternative function in mpconfigboard.h are you then NOT
allowed to use it as GPIO?

Edit:

• doing the same with /jkorte-dev/micropython-board-STM32H723VGT6 keeps the board running.

So, I am guessing something on the board died when I modified a hw_init script.