You already have working A* algorithm, and it takes the red wall into account. Can't you just provide information about other units to this algorithm in the same way you provide information about the wall?

golergka's advice is sound, though it can be kind of fiddly to constantly be updating which tiles are blocked not blocked. Or are you using a navmesh? Much more of a pain to update that, though it's doable, I wouldn't suggest it unless those units are immobile for a great deal of time, like deployable turrets. The steering algorithm should work, it's probably just an implementation issue that your units don't have constant speed after using it.

I am using A* on a classic grid, but taking all units into account would mean repathing all units when one unit moves. Units are usualy only immobile for a very brief time, so thats not happening.

When using classic steering, a unit will get stuck between two stationary units which are sitting next to each other. Imagine two circles touching each other - the 3rd unit will get stuck right between the two, because the repulsing forces cancel each other out. Can post a picture when I'm home.

I am using A* on a classic grid, but taking all units into account would mean repathing all units when one unit moves. Units are usualy only immobile for a very brief time, so thats not happening.

When using classic steering, a unit will get stuck between two stationary units which are sitting next to each other. Imagine two circles touching each other - the 3rd unit will get stuck right between the two, because the repulsing forces cancel each other out. Can post a picture when I'm home.

I believe the old tile based games just had units calculate new paths every x milliseconds, sometimes only if they are blocked and unable to move. It's not great, but for a MOBA should work fine, as they tend to have very low unit counts, and players tend to click madly all over the place repathing their own character anyway. (You could even have different re-pathing rates for mobs/creeps and players)

Steering, yeah, there will always be cases that are hard to fix, you can search around to see different attempts at fixing those kind of issues.

My units are smaller than the tiles I'm pathing on, so I can't really use the pathing approach. That's why I am looking for some kind of steering method.

Sort of tangential, but have you tried just making your tiles smaller?

Then the pathing-map get to big and pathing therefor takes to long.

I'm a beginner at pathfinding, so take these thoughts with a grain of salt:

I am using A* on a classic grid, but taking all units into account would mean repathing all units when one unit moves. Units are usualy only immobile for a very brief time, so thats not happening.

How about you don't take units into account, doing the regular A* you are currently doing, and if an entity is blocked by another entity and they are within a small range of each other (i.e. "10 ft"), then, preserving your existing A*, run a smaller local A* only taking into account the nearest tiles (the tiles within 20ft) with a "goal" of getting back on the "real" path from the original A*. Take into account other units only in the smaller A*.

If the entity can't find a way around, then just let him walk through the other entity (perhaps having each entity visually step to the side to pass around each other).

To prevent both entities from trying to move around each other at the same time, have the first entity "tell" the second entity not to bother changing its path.

Your entity normal pathfinding is gameplay-related. But the entities moving around each other - is that just visual polish, or gameplay-critical? You could just have them walk through each other and "sidestep" (each automatically moves a half-tile to their left if another entity is also on the same tile).