If they get triggered, a hard fault occurs as the HAL interrupt tries to access the original definition struct which has now disappeared.

Why have the original structs disappeared?

I think it might be better to allow a user C module to register a deinit hook, to be called when soft reset occurs. Then the user C module can explicitly call dma_deinit() on those channels it wants to close.

Note that some user C modules (or other external C code) may actually want the DMA to continue over a soft reset. Eg a Bluetooth controller that uses DMA for the UART transfer, that doesn't get reset on soft reset.

In my application, the dma definition stucts are held by micropython objects that are gc alloc'd by runtime code, so these are wiped out over a reset.

Keeping some dma alive for particular use cases is a very good point though.

The suggestion to instead have the ability for C modules to register a de-init hook is far better, I can think of many use cases for this.
That being said, there was a recent discussion on discord similar to this:

Trent: Question about GC inside micropython. If I create a new object type, in C, that has resources which must be deallocated, is the proper way to do to use m_new_obj_with_finaliser() to allocate it and provide a __del__ method for the object?

https://ptb.discord.com/channels/574275045187125269/1012726673709469818/1173760875539206225

Assuming finaliser support is enabled on the port / build, is this an existing suitable way to handle C user module de-init for soft reset?

Assuming finaliser support is enabled on the port / build, is this an existing suitable way to handle C user module de-init for soft reset?

Yes! gc_sweep_all() is intended to work this way, that it calls all C finalisers on soft reset.