... so I don't think it's a routing or hardware issue there. Just wondering if anyone has any thoughts.
Sounds like a flaky hardware problem. Perhaps inadequate power supply decoupling capacitors? Or a weak or faulty power supply?
Long ago, in the early days of Teensy 3.0, there was a project that had terrible startup problems. I recall it had one Arduino Mega and three Teensy 3.0 boards. That old thread is somewhere on the forum.... In the end the problems all came down to a Traco switching power supply which needed more capacitance at its input. Traco's datasheet incorrectly said such a capacitor was only required if a higher input voltage was used. It turned out the sudden chances in power usage caused the Traco become an oscillator if the sudden change in power throughput caused the Traco's input voltage to change to much. It absolutely did need that capacitor. The datasheet guidance was absolutely wrong.
I see activity on the JTAG pins, and eventually (about 65ms after reset goes high), the oscillator starts.
....
it would appear that even though I see activity on the JTAG lines, the code is not getting loaded properly due to what appear to be watchdog timeouts afterwards
NXP ships MK66 chips with a program pre-loaded in the flash, so the behavior may or may not be a direct result of the MKL04. Some of the behavior you're seeing may be a result of NXP's code.
But if it is from the MKL04, the very first thing the loaded code does is shut off the watchdog. Then the crystal is started. So the watchdog isn't a likely explanation.
Reset going low seems to be what kills the oscillator
This is another case where it's difficult to know which thing is the cause of another thing. The crystal oscillator does default to being disabled when the chip is in reset. The MK66 always boots based on an internal RC oscillator. It only starts the crystal oscillating when configured by software. Also, the reset signal is a bidirectional pin, so when you see it go low, that may be a caused by the MKL04 pulling it low or by something happening on-chip which causes a reset event.
My point is some of this reasoning about causality may be incorrect assumptions.
Very difficult to know what's going wrong here. But if this is a reasonably sized batch of custom boards (how many total, how many work flawlessly, how many fail, whether they always fail the same way, and other details were left unsaid) where some work and others don't, it's pretty likely to be a hardware problem. If the build quality is very good, so the problems can't be explained by soldering or PCB quality issues, I'd look at the power supply.