Change:
if (breakpoint.logMessage || breakpoint.condition || breakpoint.hitCondition) { const messages: string[] = []; <ins> let icon = breakpoint.logMessage ? icons.logBreakpoint.regular : icons.conditionalBreakpoint.regular; </ins> if (!breakpoint.supported) { <del> return { icon: icons.debugBreakpointUnsupported, message: localize('breakpointUnsupported', "Breakpoints of this type are not supported by the debugger"), }; </del> <ins> icon = icons.debugBreakpointUnsupported; messages.push(localize('breakpointUnsupported', "Breakpoints of this type are not supported by the debugger")); </ins> } if (breakpoint.logMessage) {

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The UI allows us to click-set a breakpoint and then do "Edit Breakpoint" and set Expression, Hit Count or Log Message at any point before or during a debug session. However, not all debug adapters support these features. As soon as the debug adapter runs and capabilities are received on initialization, it should be clear if these will actually be supported. Before the debug session starts, I can hover over the breakpoint and see its details. ! Once debug session starts, breakpoint gets an exclamation point in the middle of it. At first, I thought that meant that the breakpoint was special - i.e. had conditions, but now I am realizing that it means the breakpoint has a problem. If I stop on entry and hover over the breakpoint or if I hover over it while the program is running, I do see "Breakpoints of this type are not supported by the debugger". I can no longer see all of the conditions on hover that I could see before the session started. The error message does not make it clear which of the features are not supported. That would be quite helpful as the debuggers might support different subsets. ! If the debug session hits the breakpoint, then none of the hovers are available anymore for any breakpoint, hit or not. At first I thought this was the only available behavior (see first version of this bug), not realizing that I could get more info if hovering in other conditions. It would be great if the same available information was displayed no matter when you hover over a breakpoint. ! It would also be great if the unsupported options could be disabled in the UI as unavailable while the debug adapter is running.
What you are saying makes sense, however before a user starts debugging there is no debug adapter so we can not disalow setting log points function breakpoint etc even if they will not be supported - we do not know. Yes we could disable some functionality while the debug adapter is running. For that I have decided to leave this issue open and assing to the backlog so we potentially tackle this in the future.
To clarify my original request: I am not asking for any modification before the DA runs.

I understand that it is impossible and tried to make that clear in the first paragraph of my original post. I do think that it is important to make this clear after the DA runs. Disabling functionality for new breakpoints is the the last suggestion I made and would be a cherry on top. Please do take a look at my thoughts in the middle of my original report. Depending on where you are in the program, you might or might not get a hover error message "Breakpoints of this type are not supported by the debugger", but even when you do (not always), it doesn't list any of the details. Is it the hit count that is not supported? The expression? Both? There is no way to tell.
Agree. We should improve this.
I will fix this I don't want to do this, since the fact that one debug type is running does not mean that the user doesn't want other debuggers to be run as well.