I’ll try to describe how i think they work but I’m only beginning to understand them.
In general boatloaders describe where to load code from and where to listen for new code downloads.
The standard ST bootloader will load code from a well known location on flash and will also listen for new code over swd i.e using stlink protocol.
You may alternatively want to use the dfuse bootloader that supports dfu protocol. This one shows up as a mountable usb drive and you can copy your dfu binary using a file manager.
Or you could find (or write) a serial or can bus bootloader which can be programmed over serial or can bus.
Rogerclark does have its own bootloader and i think it has some unique features (a bit like dfuse?)
From my experience with platformio, I typically choose stlink protocol and attempt to upload ‘normally’. If that doesn’t work i use the boot/reset shuffle (hold boot button, press reset button, release boot) then try to upload again. This typically nukes custom bootloader with ‘something’ that works nicely. I suspect it is bootloader 2 described here
As an example. My vesc, when i bought it, showed up as a mountable device (custom bootloader?) but after I first programmed vesc with platformio i lost its ability to mount which to me indicates I’d switched bootloader.
Vesc tool (a gui) can then no longer upload (as it used usb) until i use stmprogrammer to download the original bootloader.
Finally a bootloader, i believe can load the binary from different places in flash and some boards have boot0 and boot1 pins which can be used to select which bootloader to run.
ST provide a read only system/default bootloader, so as long as boot0 and boot1 pins + swdio and swclk pins are available, i think it is impossible to ‘brick’ your mcu.
This is how I think it works but Reality might disagree 