The search query is the `#q=something` part of the URL, whereas other parameters are stored in the URL via the query string (the part between `?` and `#`). Why is that? Why isn’t the search query stored in the query string? Why in the hash?
But once you are already on google.com search page, the entire page need not be reloaded. So google would fetch the search results for the new search string via a XHR and update the page.
In fact if you search for https://www.google.com/search?q=wonderland#q=alice, the webpage would first load the search results for 'wonderland' and once the page is loaded, there would be another XHR for 'alice' and the DOM would be updated again with the new results.
The hash state has been there since Instant Search was launched in 2010.
Not to mention, why fix something that isn't broken? There are cases for it, but it's roughly the same tech that it was 4 years ago. What would they gain by spending developer time on it?
Rare on today's web, but still a thing.
Manually editing the link causes that same fetch-render-refetch flow.
Edit: Oh, you were asking about pushstate. No, that specifically fixes the problem with the double fetch, so long as the server side and client side do the right thing to make the user see the same page for the same URL.
Pushstate just lets the JS client modify the URL without triggering a page reload, so the client can change the actual query param instead of the hash.
Things like current temperature and forecast I don't want a dedicated app for when a simple search is more efficient...
For example, I directly go to Wikipedia's page on "India " by typing wp India in my address bar using these search keywords, or search images of birds on google by typing gi birds in it.
(There's a rather cumbersome way to do the same in Chrome as well)
I have some specific shortcuts like wdir (walking directions from my home address) and some shortcuts that allow me to quickly jump to subsections of specific sites.
Opening a new tab with yt <songname> is such a habit now.
it's pretty funny
Which seems like it could be used to fool someone into thinking there really are no results for a subject.
Or to pretend Google search is broken ;)
The hash won't be sent along as part of the referrer header, so the search query won't be available to 3rd party analytics. The only way to track search queries is to use Google's own analytics, which can correlate queries to traffic since it's watching both ends of the handoff.
The technical explanation discussed in this thread is certainly valid. But it only explains what is happening. The question posed was "why". Why would a search engine implement a design that would have the effect of removing the query string from referrer headers?
Answer that, and you'll answer your question
The why is also addressed by the comments (IE only got support for pushState after the solution was already built).
Besides, for a long time, Google added intermediate pages when you clicked through a search result, adding the appropriate referrers right back in.
I don't think you need to attribute this behaviour to malice when a simple technical explanation suffices.
They could of course do it without actually adding anything to the url - but then it won't be bookmarkable (and refresh would get you back to a page without results).
They could use the new history pushstate api, but then:
1. it won't work in older browsers
2. if they wanted it to work in older browsers they'll have to shim it (which ends up using hashes anyway) - and maintain it, and it will add the the page download size, which google (at least in the main site) take very seriously.
This does not mean google cannot rewrite the url without reloading the page (via history.pushState). But less browsers supports this  (IE9, browsers from 2009, and some android browsers).
So if you want the data, you are forced to help spread the google drag net across the internet.
It's sent in a separate request.