[Google Chromecast] bhiga:
Exactly the above.

Miracast is designed for low-latency, high-bandwidth connection, hence the peer-to-peer, minimal compression.

Since Chromecast connects to your WiFi access point, putting a Miracast load on that would heavily bog down the wireless network.

Assuming a wireless source device,

A 50 Mbps stream on Miracast is just that - source device ---50 Mbps---> mirroring device

A 50 Mbps stream on a WiFi AP is double that - source device ---50 Mbps---> AP ---50 Mbps---> mirroring device

Going through the AP means the wireless bandwidth usage is doubled, just like casting device-local media to Chromecast.

Except in the case of device-local media, we have the benefit of some amount of buffering and latency is not as huge an issue because we're not seeing it on both screens so a delay in response time isn't as perceptible or annoying. It's not like you're trying to interact and have to wait a second or two after each keypress like on a slow TeamViewer connection.

There are many potential delays in the chain:

Compression on source device

It takes CPU cycles to compress data, and this creates delay, as is currently the case with the Cast extension for Chrome.

This can be offset if there is hardware-assisted or complete hardware-based compression like Nvidia ShadowPlay does, though there will always be some amount of delay as long as compression is used.

Another possibility is to use vector-based graphic commands rather than sending raster images.

An additional possibility for Android is to use "shorthand" and an agreed-upon set of UI elements. The source would say "draw menu" rather sending the actual graphics and the target would draw the requested menu using the agreed UI elements. It's like sending plaintext and a font rather than rendering text as graphics.

Wireless transmission

Source -> AP -> Target incurs delay because the AP has to forward the packets. Essentially it's a router hop.

This can be avoided by doing a direct connection of some sort, but in the Chromecast world that would mean taking Chromecast off the "normal" network entirely. That kind of goes against the current Chromecast behavior where another device can assume or override control.

Decompression on target device

It takes CPU to decompress data too, and that also creates delay, though usually less than the initial compression.

Again, this can be offset by using hardware-assisted or complete hardware decompression, but there will always be some amount of delay as long as decompression is necessary.

If using vector-based graphic commands rather than sending raster images, it's just a matter of the graphic engine's drawing speed and the complexity of the vector, unless you start using a crazy amount of shapes. Nice thing about vector is that it's scalable so you don't have to worry about bandwidth bloating as the resolution increases.

Ideally Chromecast mirroring would employ as much of the compression and decompression optimizations above as allowable on the platform.

And of course we have to remember that the source device is going to be in use during this entire ordeal, so we don't want to negatively impact actual usage of the source device.

Technicalities aside, I am very curious to see what Koush has cooked up!! It could just be a question to gauge interest, but it's Koush...