1. Default for breakpoints is to stop. Don't continue until user presses a key to do so.  Main purpose of a breakpoint is to pause and let the user ponder.
2. Default for a breakpoint is to display the file name/line number, jump to that in the editor, color-highlight the breakpoint is where stopped.  Printing an expression and continuing is, IMO, far less frequently used.
3. Breakpoint just has to be before the corresponding code is executed. Gotta be. That's what all others have. We're acclimated.
4. IDE should reject or auto-move a breakpoint that is not in a syntactically valid place in the code. Such as on a comment, outside of a function's braces; in the middle of a multi-line statement like a switch() or continued line due to a comma or any other C legal reason for multiple lines.
5. Setting a breakpoint should be EASY. Click on the valid source line. That's all. The defaults as above are used. Today, it's too many clicks and too much typing, checking tic boxes, etc.  Even so, inexplicably, the debugger seems to usually ignore the "continue" tic box being set to do not continue. In my world, breakpoints are set, then run to see what branches the program takes. Just need to know where it goes, among many source files and funcitons, less so value of variables.

End of top of my wish list.

Thanks. I'll try the global properties choice for stop/continue at a breakpoint.

The lack of breaking (pause) before the line of code at that point is executed is a show-stopper. 

Please Add to my wish list:
Have two forms of breakpoints and separate icons for such, at the user interface level; one for breakpoints that continue; one for breakpoints that pause. Different appearance in icons. 

Arguably, a breakpoint that prints info and continues is a trace, not a breakpoint, in conventional terminology.

So the jargon might make sense to call the pausing breakpoint just that - a break point. And the print+continue is a trace point.

Does Visual Studio's x86 debugging have a breakpoint that does not pause?

No, I'd like one-click things. 
Set a breakpoint with pause. One click.

Insert a trace with display and always-continue. One click.

I/we do too much debugging with breakpoints/trace to be struggling with the clumsy altering of project properties. Way too many steps.

Streamline!

And breakpoints (pausing) just have to be before the corresponding line of code is executed.