Andreas, please take care of this and target appropriately.

Here as small example:

MainModule:
-------------------------------------------------
REM  *****  BASIC  *****
REM      Main Module

Option Explicit

Private iMainModuleInit As Integer ' Private != Global

Sub Main
	ExamplePrivate()
	ExamplePrivate()
End Sub

Sub ExamplePrivate
	if iMainModuleInit = 0 then iMainModuleInit = InitVar() REM Test if
variable is already initialized
		iMainModuleInit = iMainModuleInit + 1
	MsgBox iMainModuleInit,0,"The answer is"
End Sub

REM Function for initialization of the static variable
Function InitVar() As Integer
	InitVar = 40 REM any value for initialization
End Function
-----------------------------------------------

Yet Another Module, call it for instance TestModule:
-----------------------------------------------
REM  *****  BASIC  *****
REM      Test Module

Option Explicit

Sub Main
	' The variable iMainModuleInit is declared/defined in the MainModule
	' as Private, but it's accessible from this module...

	ExamplePrivate()
		
	iMainModuleInit = 100
	
	ExamplePrivate()
End Sub
-----------------------------------------------

The documentation says that the Private variable should be usable for
the module where it is declared, but the second module could use it
and set some values to this private variable.

Another point is also that the Private variable should be Global, but
that's not the case, with the Private reserved word, you will lost the
Global property of the variable. Do we have to open another issue
about this problem ?

It's the same behavior with SO 6.1 Beta2 and OOo 1.1rc3.

Use Private to declare a variable in a module that should not be 
visible in another module (possible bug). Private variables, like 
Public variables, are initialized every time that a macro is run. 

A single variable name may be used by two different modules as their 
own variable if the variable is declared Private. This is the 
advantage of Private

-> OOo 2.0, but will probably be fixed earlier, because there's 
already an interal task for this.

Forgot to set to OOo 2.0

*** Issue 22543 has been marked as a duplicate of this issue. ***

Since OOo 1.1.1 variables declared Private/Dim on module level are really private,
but only if the new compiler Option Compatible is used:

' Module 1
Option Compatible
Private b$    ' This variable is really private
Dim a           ' This too

The reason for this condition is backward compatiblity. If Private/Dim on module
level became really private it could break existing programs. While this may be
acceptable for the Private command whose semantic is very obvious by its name,
it's not acceptable for Dim that could have easily been used in a wrong way. Pri-
vate and Dim are completely identical, so both could only be changed for Option 
Compatible.

Closed

I made a test using Option Explicit, see my next attachment :
Private is still not Private in Ooo 1.1.3 and in OOo 1.9 m65.
This issue should be reopened.

Created attachment 21786 [details]
Proof that Private still does not work

It's very simple, my example is wrong. The private state does not depend on the
"Option Compatible" but on the compatibility runtime mode. CompatibilityMode
( true )". This looks strange - and that's why I ran into my own trap I guess - but 
that's how it's realised. OOo Basic always searches for symbols at runtime and
only decides after finding the private symbol in another module that this symbol
is private and cannot be accessed. Solving this on compiler level would have re-
quired major changes in the Basic core that I did not want to do.

So this is the correct code:

REM  *****  Module1  *****
Private myText As String

Sub initMyText
	myText = "HellOoo"
	print "in module1 : ", myText
End Sub

REM  *****  Module2  *****
'Option Explicit

Sub demoBug
	CompatibilityMode( true )
	initMyText
	
	' Now returns empty string
	' (or rises error for Option Explicit
	print "Now in module2 : ", myText
End Sub

OK, it works now. 
I understand that CompatibilityMode(true) sets an internal parameter, and it can be set 
(or reset) anytime during execution.

Still a problem : this is not documented in the on-line help, not even on 1.9 (checked 
on 1.9m65).