Incorrect handling of the child breakpoints

• Count of the child BP's presented by VS is inconsistent to the GDB breakpoint table.

As it is demonstrated in the attached screenshot VS Breakpoints window displays 5 child breakpoints, though GDB reports only 3 of them:

Debug.MIDebugExec info break
Num Type Disp Enb Address What
1 breakpoint keep y 0xb7731de6 <main+6>
2 breakpoint keep y 0x9c3bec09 in engine_draw_frame(engine*) at main.cpp:127
breakpoint already hit 1 time
3 breakpoint keep y
3.1 y 0x9c3bf04f in template_func(float const&) at main.cpp:120
3.2 y 0x9c3bf06f in template_func(int const&) at main.cpp:120
3.3 y 0x9c3bf08f in template_func(char const&) at main.cpp:120

• MIEngine incorrectly allows to delete/remove the individual child BP's.

Both VS and GDB are prohibiting deletion of the individual child BP's:

VS:

You can disable individual child breakpoints, but you cannot remove a child breakpoint except by removing the parent. Trying to delete a child breakpoint disables the child breakpoint rather than removing it. The debugger remembers child breakpoints, and their enabled/disabled states, between debugging sessions.

GDB:

Note that you cannot delete the individual locations from the list, you can only delete the entire list of locations that belong to their parent breakpoint (with the delete num command, where num is the number of the parent breakpoint, 1 in the above example).

MIEngine incorrectly allows to delete a child BP - it disappears from the Breakpoints window, creating an illusion that it is indeed removed, but in fact it stays active in GDB breakpoints table.
Thus, if you delete the child BP and continue execution of the process, it could silently hit the "deleted"/hidden child BP - in such case the process execution would be silently stopped with VS UI left in the running state. It's a very confusing experience because the process execution state becomes opposite to the reported VS UI state.
The only way to continue the process execution in that case is to manually execute continuation command via the Command window:

Debug.MIDebugExec continue

Start by reproducing the breakpoint state with Debug.MIDebugExec info break and compare the GDB table with the VS Breakpoints window. Verify that child counts match, deleting a child only disables it, and continuing cannot stop on a hidden child breakpoint.