I wonder what version of KVM is used by Google Compute Engine. That version has a fantastic security record, IIRC.

Does this mean that any future projects (that are esp. VMM-sensitive) on Qubes OS shall not rely on Xen being available as an option for backend VMM?

Does this mean that any future projects (that are esp. VMM-sensitive) on Qubes OS shall not rely on Xen being available as an option for backend VMM?

I'm not sure to understand your point. Currently, it's only a matter to allow running Qubes OS on KVM.

I wonder what version of KVM is used by Google Compute Engine

According to this guy (and suggested in blog posts by Google) - "GCE is built with a forked version of KVM. Google even created their own qemu replacement among many other things in that space."

I haven't found any other details though.

Out of curiosity, is Qubes planning to deprecate Xen?

I don't believe so; they have wanted it to be VMM independent for a long time and are porting it to KVM for a variety of reasons(PPC64, better GUI passthrough, etc.). See here, here, and here

Xen will remain the default, at least for now, due to being significantly more secure.

Not sure if this is the right place to post this, but crosvm may be more interesting than KVM for a Qubes port. One of the disadvantages of KVM over Xen is that it is significantly less secure. Crosvm is based on KVM so theoretically has the same advantages as KVM, but it is written in Rust and it allows sandboxing virtual devices making it more secure than KVM. It is also designed for desktop use(as opposed to Firecracker), which is why it is also used by SpectrumOS.
Spectrum has also improved on crosvm to run devices completely separate: https://alyssa.is/working-on-crosvm/

The community is documenting pros and cons in an architectural discussion on the qubes forum here:
https://forum.qubes-os.org/t/porting-qubes-to-hypervisors-other-than-xen-abstracting-the-functionality-early-stage/23478/8

@flflover mentioned this thread there.