I will try to make a drawing of the schematic, I can't really post it here ...

Update: I tried to just set a trigger on the pin that I am constantly sending as high from the uC, and I am seeing drops of around 80ms to ground in the pin value, they seem to be quite random ... any idea what could cause this kind of behavior? Watchdog reset?

Some other kind of reset? This is really not good

I checked with the debugger, eliminated all CAN communications and left only the pin writing, but still it is there, I will try to reduce the code to just the pin writing to see if this still happens ...

Ok, after many trial and error tests I identifiend I think the culprit.

It is again the CAN transceiver!

I commented all the CAN functions and the logic works.

The CAN transceiver is also on the separation line from the 2 Ground Planes, and when the 12V ENABLE goes to 0, also the right side of the Transceiver is disabled and somehow this makes the uC get blocked

Yes, the bus off is not seen correctly by the uC which keeps on trying to send in a loop. Eventually the WDT resets the uC which makes the enable pin low and then the 5V is off and goodbye!!!
I need to build a prototype to see what happens to the CAN registers when the right side of the Transceiver is off, but this will take some time.
For now I will avoid sending when the external ENABLE is off.

Post a true schematic to show the possible sneak paths. Are you using the brownout detect? Even so, if the voltage wobbles, rather than monotonically dropping (goes down,down, up, down), things can get wacky. Why might it go up? Some parts may quit drawing current below some value, the removal of their loading lets the voltage suddenly rise slightly (perhaps due to some cap storage) as it continues to drop overall. Once the software decides to shutoff, it should ignore any condition that might tell it to restart any power supply control pin.

The delay between the 12 ENABLE going off and the uC turning it's pin off is around 1.6s, but I can't correlate it to anything in my SW.

how can that be? You monitor the pin & decide to do a shutdown, right? Once you decide, allow nothing to override or restart the pin. What part of your code turns ON the supply?

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

The hardware part is working ok, I didn't test in in extreme conditions.

The 5V supply has no fluctuations, as long as the Enable signal for it is ok.

Like I said, disabling the CAN send functions when the Transceiver is off solved the problem, the driver function for sending a message has a while loop waiting for a confirmation that either the message was sent correctly or

some busoff or another type of error happened.

I already corrected this functions once when it was hanging when I was disconnecting the CAN connection, but even with this correction it is still hanging now when the right 5V side of the Transceiver is disabled.

It would be really helpfull if anybody with more knowledge about the CAN HW can read the datasheet for the Transceiver, there are some mentions about the left and right side 5V supplies of the Transceiver going off, this is an Isolation Transceiver

for high voltages, but it seems that it is having some problems on my board even if the circuit is made exactly as in the datasheet.

I will push for a redesign of the board with another Transceiver, it seems this one has too many problems that take a lot of time to solve, and fixing by SW possible hardware problems is not a good way.

Like I said, disabling the CAN send functions when the Transceiver is off solved the problem, the driver function for sending a message has a while loop waiting for a confirmation that either the message was sent correctly or

some busoff or another type of error happened.

Sounds like perhaps a software issue, not accounting for some possible system states?

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!