Tested with MS, returns both times 10. Unfortunately, I cannot confirm it since I don't know enough about macro programming. However, the behaviour can be reproduced. In the macro guide (https://www.pitonyak.org/book/) there is a reminder:

"Constants passed as arguments by reference cause unexpected behavior if their value is modified in the
called routine. The value may arbitrarily change back inside the called routine."

Code pointer: https://opengrok.libreoffice.org/xref/core/basic/source/runtime/runtime.cxx?r=0f98bcdf#714

(In reply to Andreas Heinisch from comment #1)
> Tested with MS, returns both times 10. 

I would expect twice 11, not 10 ??
> 
> "Constants passed as arguments by reference cause unexpected behavior if
> their value is modified in the
> called routine. The value may arbitrarily change back inside the called
> routine."

This reminder does not seem relevant in the actual context. Passing a variable instead of a constant in the Main() routine does not change the behaviour.

In Excel if you remove the parenthesis from the line "Add1(a)" it will return 11 in both cases. It should look like:

Sub Main()
	MsgBox Plus1()
	MsgBox Plus1(10)
End Sub

Function Plus1(Optional a)
	If IsMissing(a) Then a = 10
	Add1 a   ' <--- Note the change here
	Plus1 = a
End Function

Sub Add1(ByRef a)
	a = a + 1
End sub

It must have something to do with evaluation of expressions... when there is parenthesis, it is treated as an expression instead of a variable being passed by reference. So removing the parenthesis make it work as expected on Excel.

However, on LibreOffice Basic the error persists even when the parenthesis is removed. So I believe this is a bug.

I confirm this is a bug. Reproduced in Windows 10! The argument is received properly while the expression is not computed correctly:

REM ***********************************************
Sub Main()
	MsgBox Plus1()			'	Displays 10		=> NOK
	MsgBox Plus1(10)		'	Displays 11		=> OK
	MsgBox Plus1(10.)		'	Displays 11		=> OK
	MsgBox Plus1(-10.5)		'	Displays -9.5	=> OK
	MsgBox Plus1("10")		'	Displays "101"	=> OK
End Sub

Function Plus1(Optional a)
	If IsMissing(a) Then a = 10
	Add1(a)
	Plus1 = a
End Function

Sub Add1(ByRef b)			'	Note the "ByRef"
	Print b, TypeName(b),	' <<<< stack parm values, type names >>>>
	b = b + 1
End Sub

Proposed patch: https://gerrit.libreoffice.org/c/core/+/124289

Investigated the error and imho it is not trivial, because every parameter is considered by reference if not explicitly set. Then the runtime decides if the parameter will be handled either by value or by reference.

For instance, if a parameter is not fixed and not of type variant the parameter will be by value. I tried to remove the fixed part, but it breaks some tests.

Maybe someone else finds a solution to this problem. The test can be taken from the proposed patch.

The bug could be reproduced in:

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 6; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: fr-BE (en_US.UTF-8); UI: en-US
Calc: threaded

No reason to change the bug status IMHO.

As far as I know, in Excel the situation is as follows.
If a procedure parameter is described without the ByVal keyword, then:
1. If an argument is omitted when calling a procedure, a temporary argument (variable) of the appropriate type is created.
2. If the argument is a variable, then if the types of the argument and parameter do not match, an error is thrown.
3. If the argument is not a variable, then a temporary argument is created, which contains the calculated value of the argument.

Microsoft glossary and comments here: https://learn.microsoft.com/en-us/office/vba/language/concepts/getting-started/passing-arguments-efficiently