The hash part of the URL, (#andmorestuff) is not sent to the server by the browser, however the query string is. (?var=stuff&another=otherstuff)
Using this to send the search to the server is smart, since the server can respond with data without an additional round-trip AJAX request. However, everything in the URL, other than the hash is read-only by client-side scripts. So, if you want the URL to reflect the search, you can either a) reload the page using the query string, or b) follow the single page app methodology, and manipulate the query string with the data, and change it using an AJAX request.
Google's interactivity, with the smoother feel of not seeing an entire page refresh (plus potentially less data being sent over the wire after the initial load) could be simply stored in an internal state. However, should the user refresh, the search would be lost. If you try going to a Google search with a search query hash, you'll notice a brief delay before the search results are displayed.
For example, in this link: https://www.google.com/search?q=original#q=newsearch
The page loads, but there's an AJAX request to the /search route with the hash-specified query, with query string parameters to specify how the data should be served. Still, the client-side script cannot strip the query string of the previous search without a full page reload.
While the info leakage is annoying, it's unavoidable in this strategy.
Note: The browser history, and subsequently the URL can be manipulated through the History API's pushState, which could be a direction Google could go in, but IMHO, the hash approach is viable as well.
https://developer.mozilla.org/en-US/docs/Web/API/History_API