sfdump and sselect bug introduced (Was: Add xrandr support)

Yesterday I got around to recompiling my ratpoison with the xrandr support 
enabled and testing it out. I must say it's a very welcome feature addition.

However one thing that breaks my scripts is that the output of sfdump no 
longer can be fed directly as input to sselect. When running sfdump with the 
xrandr patch applied I now get this output:

  % ratpoison --command sfdump
  (frame :number 1 :x 0 :y 0 :width 1280 :height 998 :screenw 1280 :screenh
  1024 :window 39845897 :last-access 48 :dedicated 0) 66,(frame :number 0 :x
  0 :y 0 :width 1280 :height 979 :screenw 1280 :screenh 1024 :window
  23068751 :last-access 47 :dedicated 0) 68

Please note how the screen numbers are 66 and 68. Previously they have been 
0 and 1.

For completeness, I should mention that sselect still expects the screens to 
be in the range that sfdump previously returned.

  % ratpoison --command "sselect 66"
  sselect: out of range

My interpretation of the documentation suggests that one should expect the 
output of sfdump to be possible to be fed as the argument to sselect. The 
manpage descriptions of mentioned commands are quoted below.

  sfdump Output all frames similar to fdump, but not limited to one screen,
	 but all screens at once and with the screen number after each frame.

  sselect screennumber
	  Switch to the screen screennumber. (If you have multiple physical
	  ones.)

I realize commit b5c1e280 disables sfrestore as broken, but have not looked 
much more closely at the code than that. I have never ever used sfrestore, 
but get the hunch that whatever broke that command might be connected with 
this.