This is definitely a bug in the Basic interpreter, because the results depend on the position of the optional argument.

Consider the two following scenarios where I add a new argument (newArg) after and before "B" in your example:

SCENARIO 1 (new optional argument "newArg" after argument B)

Sub Bug_Default_Ignored ()
	Bug_Default_Ignored_Sub	(B := True)
End Sub

Sub Bug_Default_Ignored_Sub _
( Optional A as Boolean = True _
, Optional B as Boolean = False _
, Optional newArg as Integer = 10 _
)
	MsgBox ("A = " + A + ",  B = " + B + ", newArg = " + newArg)
End Sub

Running Bug_Default_Ignored will print "A = False,  B = True, newArg = 10" (notice that newArg = 10 which is correct)

SCENARIO 2 (new optional argument "newArg" before argument B)

Sub Bug_Default_Ignored ()
	Bug_Default_Ignored_Sub	(B := True)
End Sub

Sub Bug_Default_Ignored_Sub _
( Optional newArg as Integer = 10 _
, Optional A as Boolean = True _
, Optional B as Boolean = False _
)
	MsgBox ("A = " + A + ",  B = " + B + " newArg = " + newArg)
End Sub

Running Bug_Default_Ignored will print "A = False,  B = True, newArg = 0" (notice that newArg = 0 now).

On a similar note, when a named parameter is passed, IsMissing for a preceding Optional parameter returns False although it is not supplied.
It is possible to make IsMissing return True by “explicitly omitting” the parameter, i.e. writing “,” in the appropriate place.

I suspect this is all a result of the same mechanism, so that this may be regarded as another aspect of the same bug.
Again, correcting this behaviour could break existing code.

This is demonstrated by the following test, in which the 3rd and 4th calls display the wrong behaviour.

Sub Bug_Optional_Not_IsMissing_2 ()
	Bug_Optional_Not_IsMissing_2_Sub	()
	Bug_Optional_Not_IsMissing_2_Sub	(,)
	Bug_Optional_Not_IsMissing_2_Sub	(B := True)
	Bug_Optional_Not_IsMissing_2_Sub	(B := False)
	Bug_Optional_Not_IsMissing_2_Sub	(, B := True)
	Bug_Optional_Not_IsMissing_2_Sub	(, B := False)
End Sub

' Demonstrate a bug in assigning values to optional parameters, as above
Sub Bug_Optional_Not_IsMissing_2_Sub _
( Optional A as Boolean _
, Optional B as Boolean = False _
)
	MsgBox ("IsMissing (A) = " + IsMissing (A) + ",  B = " + B)
End Sub

> Again, correcting this behaviour could break existing code.

I'm not sure there's a high risk of breaking existing code, because the current behavior is a clear bug, since the argument assumes an unexpected value... it's more likely that someone else would have noticed this and reported as a bug (as you did).

So I'm in favor of fixing this issue.

@Andreas, what is your take on this bug? Any risks here?

Fixing an issue may always result in breaking existing workflows or code: https://www.explainxkcd.com/wiki/index.php/1172:_Workflow

However, this should be fixed and imho is a duplicate of 143706

Users should have no problems if they (or their macro programmers, if different):
* Do not use macros at all.
* Only use macros to record and replay UI interactions.
* Study the release notes carefully.
* Have well-run development teams that have set up regression tests for their macros and run them before deploying a new version of LibreOffice. (Atypical?)

Problems could mainly be experienced by users who:
* Have enough programming experience to find named arguments desirable.
* AND Write macros more as a sideline or hobby.
* AND Have produced a sufficiently large volume 
Also by users who:
* Use a spreadsheet written by a user such as the above.

I have no idea how widespread the use of macros is, so I cannot estimate how many are likely to be affected. My guess is that it is quite likely to affect a very small fraction of users; how small that fraction would be in absolute terms I do not know, but I guess that someone somewhere would get burned.

I should like to see this bug fixed too, but I wonder if anything can be done to mitigate the perhaps moderate risk. Obviously there should be a warning in the release notes. An option to enforce old behaviour or one to enable correct behaviour probably adds unwanted complication to the code base. It helps that it would first appear in an early release version used by risk-happy power users.

(In reply to Andreas Heinisch from comment #4)
> Fixing an issue may always result in breaking existing workflows or code:
> https://www.explainxkcd.com/wiki/index.php/1172:_Workflow
> 
> However, this should be fixed and imho is a duplicate of 143706

I agree that this is essentially a duplicate. What this perhaps contributes is these regression test cases:
* If there is no default value, IsMissing should return True (and accessing the value throw an error).
* If there is a default value, it should be applied (especially if not the default for the type!).

Good XKCD!
(People abusing weird behaviour deserve what they get, I care more about those who accidentally depend on it.)