I'll go ahead and try to address these now and then translate them into the FAQ when I get to that point (didn't want you to think I don't value these submissions):
Size and positioning of windows does not throw change events, but will always return the client-side values since the call itself requests information from the client. It is important to know this as it can create short wait-states in your code while it does a round-trip request.
Testing is not explicitly enforced in any way as every UI component is a simple bean so the entire UI can be programmatically tested without any implementation defined.
Focus is something that is not completed. When Beta 4 is released events will be thrown for focus and blur. For now, any component can request focus via the Component's focus() method.
The lifecycle of an application in the Flex implementation (lifecycle is implementation specific obviously) is page based with a generated session id. That session may be reconnected to if the Application in question is set to "persistent". Otherwise, a new session is generated and thus a new application instance is created.
Model binding is something that is not explicitly supported in jSeamless, but is something on the agenda for jSeamlessX (the extensions project) and will provide a great amount of functionality for dynamic UI generation for Beans and mapping capabilities to map that data to/from the UI.
Layout management is something that is handled differently in jSeamless than in other frameworks such as Swing. Instead of a LayoutManager that is applied to a container, the container itself is a layout manager. For example, Box is one of the most common containers, and simply organizes components in either a single vertical or horizontal line.
Dimension (which needs to be JavaDoc'd) is an encapsulation object for width and height. The width and height values can be represented in three different types: Pixel, Percentage, or Auto. The only one that may not be readily understandable is Auto, but as the name suggests it simply allows the parent container to manage the value based on the components needs and the parents restraints.
Architecture overview I won't go into here, but I have plans to have lots of pretty UML diagrams.
Server load will also be explained more with diagrams.
Existing web site integration isn't as simple as I'd like it to be currently and so it's not "officially supported". However, it will be supported in Beta 5 or 6 depending on need.
Unit tests are currently not implemented, but it definitely something needed. Any contributions of such tests would always be appreciated.
Comparisons to other technologies will probably be an extensive document explaining the differences, but that falls at lower priority since functionality is the most important at the moment.
