When working a bit more with jMonkey, I start to wonder what's with this obsession with keeping data close to the scene graph nodes? The vertices are all owned by the mesh batch, and to share meshes, you need a special "SharedMesh" node. It also doesn't support a shared vertex buffer, used by multiple batches. The animation skeletal bone is spread across special "Bone" sub-nodes. And the actual animation info – it's stored with the nodes! This makes it a lot harder to share one animation across a number of different meshes.
I realize this was the way Eberly's scene graph started out (a long time ago), but even he has started realizing that Nodes aren't everything. And with modern art, the ability to share and re-target all kinds of data (vertices, materials, animations, skeletons, etc) is quite crucial. I guess it would be less of groping around in the dark if I had an idea of whether 2.0 would start addressing these issue. Is there a public roadmap for 2.0 available somewhere?
Typically, you want to keep data separate ("Mesh," "Skeleton," "Animation," "Texture," etc) and then use instances for the scene graph layer ("MeshInstance," "SkeletonInstance," "AnimationInstance," "TextureInstance," etc). The nice part about that is that all the heavy data can be managed in any way you want (including living in a large byte array loaded as part of a level), and the actual run-time modified data lives in the instance classes, with clear delineation of responsibilities.
You’re very much right… IMO the scene graph should only contain references to data, which is managed by a special resource manager class. Right now this is only supported through the TextureManager class, but it works by making copies of textures and to me it seems a bit hacked.
The “roadmap” for 2.0 is available in the wiki page jME 2.0 todo list, it’s somewhat official (been edited by renanse), you can add what you feel is important by editing the page. Also at this point of time I think it’s very important for individual users to contribute :), you seem to know what you’re doing, so maybe you might want to apply to become one of jME’s official devs?
Things has evolved quite a bit even in the short lifetime of jME. All the things you are talking about are being considered for 2.0(yeah, we've read the new eberly books as well). We didnt want to rewrite the complete core before the 1.0 release. We'll get some information out on the plans on core changes etc on 2.0 as soon as possible, and a new repo for that development as well…
Looking forward to getting lots of discussions going after we make things "live" with 2.0 pre-alpha-0.00000001 
Seems like you spent a decent amount of time in the XNA community as well, any thoughts you might have on what you liked from there and why you started looking into jME would be of interest. 
As I said, my hobby is “collecting” graphics engines. I have made contributions at least to the following communities:
ODE
Ogre3D
DeleD
C4
Torque
XNA
and, if you count the small patch I made to the binary writer, a small contribution to jME
I’ve also looked at or worked with a lot more engines (many of which are derivatives of the above) without feeling the desire to contribute anything.
I’m not looking for a community to join, unless there is a community of engine reverse engineers who want to collect knowledge about how things are done in many different places, the better to be able to choose the right tool when needed. However, if I find myself improving things as I’m going through them, I’m happy to share. (I’ll put up my new ASE exporter when I’m done with animation, for example)
At work, I have worked on at least two generations of a graphics presentation system built on both Direct3D 9 and OpenGL 1/2. I am also the (spare time) author of the most robust .X mesh exporter for 3ds Max I know of.
In one sense, you can happily ignore me, because I probably won’t still be here two months from now. On the other hand, I feel as if I’ve colleced a bit of graphics programming wisdom over the years, and if some of the things I say end up making the engine better, then everyone benefits a little bit.
XNA is cool, because it runs on the Xbox. It’s also nice because Visual Studio with C# is nice. They’re making some strides towards making the usage model (device loss!) simpler in 2.0, too. However, it’s not an “engine” as much as a “graphics library” – they say it themselves; they only provide low-level access, and let other people put scene graphs on top. The unfortunate part is that the .X mesh functionality found in the D3DX library isn’t actually exposed in XNA. They have a little bit of the static part (calculating normals/tangents/bitangents, etc), but none of the animation/skinning part. And the community skinning component available for XNA isn’t particularly great, IMO.
All different libraries have their strengths and weaknesses. However, when it comes to graphics, what I find is the main sticking point with all those libraries is that the art path doesn’t hold up. When it comes to animated, skinned characters exported out of 3ds Max, they all fall down with half-implemented runtimes, crashing exporters, and bad data processors. That’s where commercial libraries have all the indie options beat – Granny, Gamebryo, Unreal, or my work stuff is all so much more solid.
I think jME, with a re-imagining of the data-vs-control-information separation, and a solid path from Maya and Max, could make real waves.