Hey, I've had a play with Akihabara along with gameQuery and was mightily impressed by both, and for single player games they are pretty ideal in terms of how they work. From what I was able to gather from looking over the code it shouldn't be to complex to implement a multiplayer browser game. The issues I found were more to do with scale, and easy of expanding the content.
What I mean by scaling is that because it is using canvas to render its content you'r going to run into issues supporting a wide range of browsers, and even then firefox's canvas support is pretty horrific, unless you start using tiny view ports, which to me is not acceptable.
As for expanding the content, normally in 2D multiplayer online games you need a vast amount of variable content, the two ways I see to implement this effectively is to either pre-render all of the content into 1000s of tiles then download and stitch them together, or to download blocks of tile data, and draw it on the client. Each technique has its own pros and cons, for example using the pre-rendered method your able to cater for people with lower spec machines, or older/slower browsers, but your bandwidth usage skyrockets, using the client to render the levels makes it easier to implement collision detection, but puts a ton of additional load on your client. Akihabara and gameQuery both use the render on client method.
Within Thorny by default I am going to be implementing the pre-rendered method, mainly because it allows me to use external applications to draw my maps, which cuts the amount of work to implement the game, though this has caused some interesting data modelling problems and has made implementing collision detection a pretty significant issue.
I can't wait to see what you come up with, unfortunately Thorny is a way off, so it will be a while before I could recommend using that instead, though even then you'd need to take my recomendendattion with a grain of salt
