All these are opinions, of course, but here are some ideas for making JME easier to understand at a glance.
1.
- yeah, would probably be better names, but I don't think it's worth the hassle for people who would have to adapt their existing code
- interpolation == secondsSinceLastRender is not always true
- yes, I'd like that, too. Unfortunately it would require different handling of vectors and quaternions in the scenegraph. Because atm the engine can't notice changes to local translation, rotation etc. So it would require a major API change with a lot of impact on existing apps… so it most probably will stay that way quite a while
to 1.: you can still move the code to the new method and deprecate the old ones(which of course would call the "new" methods). that's the way APIs change.
these suggestions would definatly make JME easier to understand but after a while i could find them getting annoying the. Doesn't the inustry as a whole use the term resolution, and use the term time to signify how long the timer has been running and not as a "what time of day is it?".
Here's my nitpicking 
- Yes, some methods in the API could have been named better, but it's not really important if you ask me. Eg. why use getTime() to get the Time? Doesn't Java have a whole package full of classes to do such things?
- Irrisor answered that one (the javadoc mentions this too)
3.
This is the most important point… and in a way the one with the most merit. After all this is what most new users struggle with. I too raised my eyebrows when I was new to jME and suddenly my mesh had the font texture cause I forgot to call updateRenderState(). but it's important to realize why those methods are there, what they do can become quite expensive to use in certain situations, which is why they're not called automatically.
A "dirty" queue would be part of a solution, it still leaves one question unanswered. When do you process the dirty queue? For most users that indeed is every frame before you draw, but that's not always true if you start doing more advanced things. Maybe it's an idea to have a "simple" and "advanced" mode in the future, but I'd be against giving up the control you can have now. It's not an ignorant observation by any means.
irrisor said:
2. interpolation == secondsSinceLastRender is not always true
This is a circular issue.
Eg. what if you want to slow down time? The Timer class is only a utility for SimpleGame… it's (imho) by no means a perfect solution for all game types.
So to sum it up, there's lot's of things you can do with update(). But even update/render etc. is only a refence structure for making a game. None of the jME components require you to use actually use AbstractGame.
You might also want to measure in "steps" instead of time. I've asked this question myself and in my own code I actually just populate the interpolation value with time between updates, but in SimpleGame it always receives -1. However, I think it is beneficial that it does not impose on the developer what that should be even if in the majority of cases it would be time per update.
darkfrog
Also, when working in eclipse with autocompletion and stuff like that, tag-insight or whatever all those neat features in eclipse are called 
it would be great to see something like:
display.createWindow(int width, int height, int depth, boolean fullScreen)
instead of:
display.createWindow(int arg0, int arg1, int arg2, boolean arg3)
Simple things like that can make life easy.
It does that if you're pointing to the source code. 
(does it on mine at least) :-p
darkfrog
Or maybe if you attach the javadoc zip to the library. At least that's the way I do it in InteliJ IDEA.
If you set the source code pointer in your project to an eclipse jME project make sure the jME project is opened. Eclipse won't look in closed projects.