I got a board made of rev 5.1 - the same as the 5.0.2 board but with the footprints added for a 3.2x2.5mm 4-pad crystal and two loading caps on the R port pins. I built that board this evening with a 16 MHz crystal in place, and added support in the code to use the external crystal oscillator and PLL (configured to double) to make a 32 MHz clock. My motivation for doing so was to compare the stability of an undisciplined crystal against the FLL disciplined 32 MHz XMega RC oscillator.
To measure it, I modified the code to display (instead of the time) the delta of the number of ticks in the capture ISR and the expected value (32 million).
As I kind of knew from experience, with the FLL corrected RC oscillator, it bounced around fairly wildly several thousand ticks in each direction. The crystal oscillator, by contrast, stayed fairly consistent. In this particular example, it was about 1080 counts slow - about 33 parts per million. If I put my thumb on the crystal, I could get it to diverge a handful of counts or so over the course of a few seconds. That too is kind of to be expected - crystals are sensitive to temperature. But still, the crystal is by far more stable than the RC oscillator. Again, not an unexpected result.
I'm still undecided whether it's worth adding the part. Unlike the case with the ATTiny841, there's no speed advantage to adding it - the chip still runs at its maximum 32 MHz speed. But if the system clock were that stable, we could switch the firmware over to using a free-running, disciplined clock model as opposed to the absolute interrupt-driven reactive model the clock uses today. In other words, we could just have the capture ISR record the timestamp of the PPS rising edge and let the clock tune itself. Doing so would allow us to reclaim most of the 70 µs capture ISR latency, though we still would likely be stuck with the 100 µs worst-case display update latency. So we'd potentially be able to cut the accuracy spec in half (in fact, if we ran the clock 50 µs ahead of actual time, we could instead wind up with a ±50 µs spec instead of a 0-100 µs slow spec). We could even potentially dare to allow the clock to free-run if GPS drops out from time to time (though that raises the specter of having to quantify how long free-running is acceptable, or how to indicate it and so on).
That is, however, a mighty big firmware change for a very, very marginal gain for a clock that only has 100 ms granularity.
Still, since the clock works, I'll commit the code changes to the GitHub repo and upload the latest schematic and board files. You have the choice of populating the crystal footprints with a 16 MHz crystal or not populating them. There is an XTAL macro in the code that determines whether or not the firmware will attempt to use it.