Why don't SharePoint search-related web parts use connections to communicate with each other?

Question

Why don't SharePoint standard search-related web parts use web part connections to communicate with each other? They use QueryManager instead which is placed into Page.Items. I'm trying to understand the tradeoffs here. Is there something that was impossible to achieve using connections?

Answer 1

I think the real reason is that the team that developed these controls initially didn't know how to use web part connections.

But it gives the following advantages (which MS probably will claim is the reason).

Easy setup on single query page
On most search pages users only have a single query. The current implementation makes it easy to add new search web parts as you can just add them to the page and they automatically use Query1 as all the others.
Most uses don't understand web part connections and this setup makes everything simple until you need a second query, but then you still only have to configure a simple setting on the second set of web parts.
And 5 queries on a page is enough for EVERYBODY, so what's the problem?

Don't rely on any search web part being on the page
The current implementation don't rely on any of the web parts to be on the page, you can mix and match any combination, if you only need a count the don't include the CoreSearchResult. Using connections this would be very hard to make possible.