First of all, thanks for all the input! This will really help me a lot.

Interesting. In the unaligned collision avoidance description it says that he used containment steering behaviour http://www.red3d.com/cwr/steer/Containment.html for collision with the surrounding (the grey areas) which is exaclty the java app I was looking at when I made my original collision-avoidance.

Okay, the reason I was/am so fond of these flowchart-elements:

The top part of the image displays what this containment steering behaviour did for me.
I have many asteroids in clusters. In such a cluster, it can (and often does) happen that two asteroids are very close to each other. This is cool for multiplayer action, because loosing rockets and enemies is much more interesting, but it totally killed my collision avoidance. Here, this is what happend: The ship was on the left, and tried to get to the blue cross on the right. It "saw" the asteroid, and steered to avoid it. Once having avoided it, it steered back towards the cross. Ahead of it, there now lies another asteroid, but by using the normal like he did in the containment steering it just drives me deeper into the small area between the asteroids, out of which the ship doesn't get out any more and crahses (acceleration/decceleration aren't large enough to stop the ship in time and make it go around). A human player would see the second asteroid and go around that one too, before steering towards the cross again.
His app doesn't have any sharp concave areas, so he doesn't get that problem.

Lower part of the image: This is the reason I was thinking about using direction nodes, or flow chart like behaviour: If I somehow managed to precompute and place nodes around the asteroids which point into directions towards the next node, then I could make the ship follow these and avoid having to compute a useful path in realtime. That was my thinking here...

I was going to extend the flow direction nodes around each ship out infront of it, to make other ships try and "flow" over or below it. But I like this "unaligned collisions avoidance" and think I will use this instead. It should be much easier on the cpu, though of course also complicated to implement with rotation and movement in 3d space (why didn't I make a normal 2d-plane game instead? *sigh*). In the app, there's quite a few collisions, but then again there's much more entities than I'll be having in such a small area, with the playercount currently limited to 16 players.

So I can try to use the unaligned collision avoidance (it'll need quite some adaptation, because I also have ships of varying sizes) for the avoidance of collision with moving entities. But I'm still no further with the avoiding of asteroids...

Sorry, I was gonna make this post shorter, now it ended up being a monster-post again O.o...