I see the issue of preserving state as being more of a means than an  
end.  When I'm pitching the importance of Seaside I tend to focus on  
two things:

- reducing the amount of context a given piece of the UI model has to  
  know to be useful; that is, having web pages that don't have to know 
  which page came before them or which might come after them, and  
  having sections of a web page that don't know which sections 
  surround  them or which they enclose.  This just sounds like 
  Encapsulation 101  but it's absolutely *not* standard practice in 
  web development,  despite the obvious maintainability advantages.
- reducing the manual bookkeeping work required when transferring  
  messages between the server and the client.  Traditional web  
  application development spends an obscene amount of time shoehorning 
  data into strings in URLs and form fields and making sense of those 
  same or similar strings that get pulled out of subsequent HTTP  
  requests.  In Seaside you never see anything at that level unless 
  you  really, really want to, and that alone can cut development time 
  literally in half or more.

Now, both of these things are indeed *enabled* by the approach to  
state management, which is to keep a huge amount of it active, in  
memory, for each web session.  I joke that Seaside takes a "share  
everything" approach, in contrast to the conventional wisdom of  
scalable web application development which is "share nothing" (ie, be  
able to recreate the full state from scratch on every request so that  
any server running the same code could handle it).  Rails,  
incidentally, comes down very vocally on the "share nothing" side so  
I wouldn't characterize it as being "primarily concerned with  
preserving state" at all.  You might say that Rails is concerned with  
building elegant and convenient models of statelessness, whereas  
Seaside is concerned with abstracting the statelessness away to the  
point that it feels stateful.

> Also, is there an advantage, do y'all think, in Smalltalk having a  
plug-in VM? That is to say, do you think it's easier to segue from  
Seaside to a rich-client type experience in Smalltalk than these  
other technologies?

Not in the sense of actually integrating with rich clients, no (or  
not enough to matter).  Somewhat in the sense that the general feel  
of Seaside is much closer to that of rich client development than  
most web technologies provide.

Cheers, Avi