After "Connect to Target", the firmware appears to be running OK but the information in Ozone is strange. The system uses STM32 HAL which uses 'uint32_t uwTick' for system ticks (milliseconds). If I watch it live, it should increment at about 1000/second. It starts to do that, but then occasionally jumps to a strange number. It then changes back to the correct value as if it was still incrementing correctly. Each time it jumps to the strange number it is the same odd value. Other static/global variables in the system behave the same way. I use uwTick as a sanity check.
We use STM32H743. The system has a bootloader as well. Trace is enabled via pins (J-Link Pro Cortex M). Trace has been working for a while now.

I have narrowed this down to requiring an Ozone debug connection to the device after a power-cycle and before the bootloader starts the application. Once that is done, I can use Ozone to reset the application to main() and run from there. At this point, I can even give the device a user command to reset, and the bootloader will start the application (leaving the debug session running). I can exit the debug session and connect to targe and it works fine. Trace counters don't work when doing that, but the live variables look good. Performing a reset (F4) and restart from main() works fine. But if I disconnect and power-cycle it acts up again when I connect to target.

Debugging in general has been working well for a few months now. This came about when I was trying to debug a .out file built on another system. We map appropriate paths for the .out file using Project.AddPathSubstitute().

I am trying to connect to the running application after it has fully booted up.
When I do that, the live watch variables display erratically. I expect to see live variables in the watch window to display predictably.
I am not saying that I can never get this to work.
It will work as expected if I am able to connect before the bootloader starts the application. This is only necessary after a power-cycle. Once it starts to work, I can connect and disconnect all day until another power cycle.

For now, I'm sticking with the solution of adding a conditional delay in the bootlaoder (when code detects a boot from power-up). Connecting Ozone during this delay resolves the issue.

What you have described is correct.
I would clarify to say the method to connect is "Attach to Running Program" <F5> after a power-cycle. The application has been started by the bootloader before connecting. This is where the odd behavior starts.
At this point (while connected in this odd state) reset the target via <F4> and it will startup and break at main() per usual. The bootloader does not execute with this kind of reset (or restart). Bootloader is not required to run before the application either. This should give a fresh clean start of the application. But after letting it run, the odd behavior continues.
I checked the links you mentioned, and they don't appear to apply to this particular problem.