I'll cover some of your points here, and other ones on the engines mailing list.
my understanding is that plugins' approach to anything with views is to use generators. you cant actually have view/controller code in the plugin?
That's correct, although some of the recent changes in edge rails make it slightly easier to load views from different paths (http:// interblah.net/2007/2/5/more-plugin-power-goes-into-rails-core). However, for Rails 1.2.x, the engines plugin provides the small amount of patching required to load views from plugins.
- dependencies on main app / models first, there are dependencies on the main app's user model.
Is this a problem? Your shared code simply requires some objects for working with the user accounts that respond to a set of well-known methods. Even if your user accounts use different tables in different applications, this can normally be circumvented by using a common interface (i.e. a current_account method somewhere) to access it. Regardless, this isn't a significant problem until you start sharing your forums with other developers whose code you cannot control.
- migrations there arent easy way to share migrations with the main app and an also evolving plugin.
I presume you've seen the migration integration that the engines plugin provides? This works very well as a solution for evolving the schema required by shared plugin code.
- getting added code back into plugin a generator is basically one-way.
This is basically the primary motivation for enhancing plugins in the way that engines does.
- view helpers? since plugins support -view helpers- we could rewrite the forum views all as helper methods.
This might be possible, but it's such a departure from how you typically develop a Rails application, is it worth pursuing? You will also encounter problems when you try and delegate production of views to designers if you choose this route.
- installing partials another thing some people seem to do is have the installer copy some partials into the main app.
That's definitely a possibility, but you'll run into the same "generators are one-way" issue as before.
- can a plugin include a controller? i guess it could include a library, which is a module that the controller in the app could require...
The easiest type of non-typical code to include in a plugin is a controller - if this is all you need, there are solutions which exist for doing this without including the engines plugin (google is your ally here). However, these still involve playing with some Rails- internal functionality, only this time it's in your plugin's init.rb file, rather than being provided by another plugin (engines). YMMV.
"engines" seem to allow most of what i need, but they dont seem to be getting much use.
Regarding your other concerns about engines being unstable and so on... this is only really a concern if you like developing against edge rails, and the same concerns exist on any code that you rely on but aren't responsible for.
If you feel like you need some of the functionality that the engines
plugin provides, take a look at it. You're certainly free to tear out
the methods that you need and discard the rest, if that feels like a
safer approach 
- James