1) What would be a good design practice for enabling components to speak more than one output dialect? ie. an HTML output format and an XML format

Hmmm. Components get their chance to emit their output in appendToResponse (in the java version) or it was called appendToResponse:inContext: in ObjectiveC. If you're using GSWeb I'll assume its Objective C from here on out. The main loop looks like:

Application>>handleRequest:
Session>>awake
Session>>takeValuesFromRequest:inContext:
Page>>awake
Page>>takeValuesFromRequest:inContext:
Components>>takeValuesFromRequest:inContext:
-- at this point everything is about copying state from browser into session/page/components
Application>>invokeAction:
Session>>invokeAction:
Page>>invokeAction: (your action method gets called -- ie whatever action was bound to the link/button they clicked - if any - you should return the next page or nil if you want to redraw the current page)
-- so you did something now answer the response
Application>>appendToResponse:inContext:
Session>>appendToResponse:inContext:
Page(the new one)>>appendToResponse:inContext:
Components>>appendToResponse:inContext:
-- after this - sleep gets called on everything that got an awake call.

2) Similarly, design practices for internationalizing output.

I have a vast amount of code that does this stuff. Out of the box, WO wasn't entirely international ready - I don't know about GSWeb either. We developed components that automatically internationalized stuff. So instead of WOString we used ETString everywhere. What these components did was look at what you would normally emit in appendToResponse:inContext:, notice what locale was in the content/type header (which we set up in Application early in the loop), then open a resource file and get the appropriate translation for the string that was supposed to be emitted. A strings file is basically a dictionary plist with the english text as a key and the translation as a value. Thats translation. We wrote number/date formatters that did internationalization too. The idea was to just write the app as if it were in english, then the components would deal with internationalization. There is also a locale bundle mechanism that lets you serve a completely different page based on locale. The idea is you have a resource directory for each different language - like Spanish.lproj. WO will try the specific resource dir first, then fall back to the main one. So if you wanted to do a site for hebrew and lay everything out right to left, you'd put all the page resources for the hebrew site in Hebrew.lproj, but use the regular layouts for all the other languages and just use strings files.

3) And this one is probably going to prevent me from using GSWeb: those stupid URLs. They make a persistent URL impossible. Any strategies to get around that?

There is a thing called a direct action - these are bookmarkable - but you don't have session information (obviously) in a direct action. The response loop is a little different for DAs. It looks like:

Application>>handleRequest:
DirectActionClass>>alloc // a new instance of the DirectActionClass is created
DirectActionClass>>yourActionMethodWithTheRequest: // you return the response

What you could do is write *one* direct action that pulls out your own sessionId from the cookie, then forwards the request to the right session - basically taking over Application's job of looking up the session in the direct action. Certainly doable.

I tend to only keep a session for a logical unit of work/transaction. So you start with a direct action - pick what you want to do - use the session to manage state while you build up your unit of work, on commit I return a directAction which essentially abandons their old session (you can call sesssion terminate to kill it right away) and gets them out of stateful mode. This seems to work the best.