For one, widespread support for that feature is relatively recent -- in fact, it's slated for the next version of IE.

For another thing, it's a bit more complicated to implement (you need to have a valid URL for every little piece of every page on your site) for not a lot of benefit that most people would notice. In fact, if you don't do them really well, it might confuse people when their bookmarks don't take them to the start of the page. They're sort of the awkward middle child between permalinks to an index and permalinks to posts, and even if they were there people wouldn't want them as often as the other two. This would probably put it in the "Maybe get to this later" pile.

Well, the inconsistencies between browsers is quite a good point if it would cause inconsistencies in user experience.

I'd like to point out, however, that FB already does some kind of similar trick with the URL hash when browsing photos: if you open someone's photo, it'll open in a modal dialog where you can navigate to other photos and this in-page navigation _will_ change the URL hash. If you go to that modified URL directly (or refresh the page) FB will show a different page (inside the person's "album") with that photo.

I'd reason that, for FB, a photo is more of a tangible thing than an item in your infinite stream, thus it deserves separate URLs when browsing the them.

replaceState still works for changing the hash-code without updating the history list, so you can stay on the same 'page'. You can then read the hash-code using browsers like IE, just not create new ones. I used this as a quick hack to get permalinks on http://ares.aylett.co.uk/xkcd/ -- when you move (on at least FF and Chrome, but not IE), the hash-code updates, and at least FF, Chrome and IE can decode the hash-code on page load.

Not to say that I don't agree with your conclusions about infinite scroll -- I'd much prefer sensible pagination.

what chc said plus load times, it would take like 6x longer to load such a web page and as chc points out most of the time you don't really care, now if there was a way to say, take me back to that state or just take me to the top... that might be interesting but that's way too complicated for the average user. (Maybe a FB+ addition)

About the load times, the could be minimized. If you go back to item #235 of your stream, FB could avoid sending you all the 234 preceding items.

Also, yes, i agree in that it could be perceived as a strange behaviour, but to me the current behaviour is also quite strange: if i'm scrolling down the FB stream, triggering a couple of stream sudden enlargements, then go somewhere else on that tab, and then go back to the FB stream, the browser will remember my last scroll position on that page and will try to scroll down to where i was, unfortunately that position does not exists when the page is loaded so it ends up scrolling to a seemingly random point in the middle of the stream (actually it's the bottom of the stream when the page loads, but that triggers a stream-append and then it's not the bottom anymore), not where i was before nor at the start of it (at least this happens in Firefox).