Some points to discuss:
Provide a common interface for static geometry loaders
I think this is a "1.0"-feature. We cannot speak of a stable 1.0 API when it's that inconsistent like the model loaders interfaces as they are now. So I really think this point is better nested on the 1.0 dev-plan like it already is.
Since FengGUI already aims for kind of general purpose GUI, I would suggest to keep the HUD at a minimum. Just some textured Frames with buttons and a simple text input. Maybe scrollable surface and/or lists at most. No fancy widgets like trees and such, no layout managers, no xml description language. Just a quick way to make start-screens, highscores, inventories etc.
Maybe this text would be better:
Since FengGUI aims at rich GUI applications, the HUD should be kept at a minimum, which is needed to create GUIs for games: Static Widgets like Buttons, TextFields, Labels,, Images, RadioButton, Checkboxes, Lists, Tabs, Panels, Frames... the most basic Widgets needed to make start-screens, highscores, inventories, etc.
No need for fancy Widgets like Menus or Trees.
I want to be able to track the position of an object in a small overlay on my screen. I want to be able to explore the Appearance of a Shape3D. I want to know what are the incoming events. In real-time (Re-use onyx appearance editor ?)
I think, this is a job for a small Swing application.
4. Java shell
BeanShell is a very good one.
1. Display Lists
I'd prefer flags, too
Niwak (vincent) mentioned a bug in the atom sorting algorithm. This has to be "sorted out" and fixed.
This is an urgent bugfix needed in 1.0, too. So I think it's not a "2.0"-feature.
Who knows a friendly software engineer ?
Am I friendly? Well, at least I have some knowledge on Software Engeneering.
The dev-plan shouldn't include points about bug fixing. Bug have to be bixed in version 1.0. When we have a stabe and clean API 1.0 with no known bugs, we can proceed with 2.0.
anyway... really good work, Amos