I managed to reproduce the issue using the "scopes" test application. The trick was to change the org.icefaces.windowScopeExpiration value to 3000ms. The steps to reproduce are:

1) Load http://localhost:8080/scopes/window-scope-A.jsf in first browser.
2) Load http://localhost:8080/scopes/window-scope-A.jsf in second browser.
3) Restart web server.
4) Reload http://localhost:8080/scopes/window-scope-A.jsf in first browser.
5) Increment counter to 3.
6) Reload http://localhost:8080/scopes/window-scope-A.jsf in second browser.
7) Observe counter value in second browser, it will be 3 instead of 0 as expected.

The reason why this happens is as already noted, the UnusedScopeMap is created during dispose window request of the first browser (when reloading page). The UnusedScopeMap continues to be used when incrementing the counter (because of the windowScopeExpiration lengthening). The reload done by the second browser triggers a dispose window request which will not create a new UnusedScopeMap but use instead the one already created (since it's assigned to a static field). This way the page load in the second browser will continue to use the same UnusedScopeMap that has been created by the first browser.

When the window ID cannot be matched against any of the scope maps (active or disposed) then most probably a postback was received after the server or application was restarted. Create a freshly new ScopeMap to be used by the rest of the JSF lifecycle and by next page load (if issued during a reload).