*and* letting them load bw-interactive.el if they want to resize windows
interactively looks fine to me. It's simpler 1) not to rebind C-x + and
2) to have C-x + balancing the windows (instead of C-x + + which add one
keystroke.)

bw-interactive lets you do this quite easily, with just "C-x + +" (today
it is on "C-x +").

My point is precisely that C-x + is fine as it is.

And mine is that resizing windows should not occupy more human memory
and key binding space if possible. "C-x + +" is nearly as easy as "C-x
+" to type.

I don't suggest that bw-interactive.el should tell the user what is
going on. I suggest that `bw-start-resize-mode' start listening to the
next keystroke (as it does) and that the next keystroke take immediately
action. Again, it's more intuitive to me that C-x + <up> increase the
vertical size of the window immediately.

See above. You have to decide which border to act on first.

I tried to mimic the way this is done some OS window handlers.

Which one? I'm using ratpoison. C-t C-r does the job of your C-x +,
then C-f will enlarge the ratpoison-window immediately, no need to press
C-f twice.

Eh, I am using w32. Do you mean that ratpoison interfere with Emacs key
bindings?

When you start resizing you get into a state where the window handler
first needs to know which border to move. The mouse pointer is then
moved to that border.

Isn't that simpler to move the border when you know which border to
move? Maybe I'm too much thinking the ratpoison way here. An example

of a WM implementing the behavior you suggest would be useful, because
I honestly don't see why this has to be a two-step process.

I tried to explain above. Is it clear now? (Or have I perhaps missed
something?)

Maybe adding a message of some kind when exiting the minor mode for
resizing would make thins more clear?