Code pointer:
https://opengrok.libreoffice.org/xref/core/basic/source/classes/sbunoobj.cxx?r=fbc038cc#3118

On pc Debian x86-64 with master sources updated today, I could reproduce this.

Since in this part:
   3171     if( x1 == x2 )
   3172     {
   3173         refVar->PutBool( true );
   3174     }

x1 isn't considered as == to x2, refVar stays at false.

Now I don't know how to fix this or if we should fix this.
Indeed, I suppose it may have impacts on existing macros.

I should subjoin that even the expression 

EqualUnoObjects(ThisComponent.Sheets.GetByIndex(0), ThisComponent.Sheets.GetByIndex(0))

will return False.

Created attachment 151602 [details]
EqualUnoObjects - working example with controls

adding a working example, searching a control on drawpage

You may also have a glance at a related post in a forum where sometimes actual discussion occurs: https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=98435

We actually do create a new object each time a range object is requested (see e.g. ScTableSheetsObj::GetObjectByIndex_Impl[1], which implements functionality of XIndexAccess::getByIndex). So at least in case of range objects (which have their range read-only, thus for all uses should be considered "same" when refer to same range), we need some special casing to check if they are objects of the same type (e.g., one could be "sheet", and the other "all cells, but not sheet", and these are different objects), and then refer to the same range.

https://git.libreoffice.org/core/+/1c3eb7e329cd2eaeb83068907ba0c9a5b3ef7852/sc/source/ui/unoobj/docuno.cxx#3577

Checked with V 7.5.3.2 under Win10

Behaviour unchanged.

(In reply to Mike Kaganski from comment #6)
> We actually do create a new object each time a range object is requested
> (see e.g. ScTableSheetsObj::GetObjectByIndex_Impl[1], which implements
> functionality of XIndexAccess::getByIndex). So at least in case of range
> objects (which have their range read-only, thus for all uses should be
> considered "same" when refer to same range), ...
  ... we need some special casing to
> check if they are objects of the same type (e.g., one could be "sheet", and
> the other "all cells, but not sheet", ...
  ... and these are different objects), and
> then refer to the same range.
> 
> https://git.libreoffice.org/core/+/1c3eb7e329cd2eaeb83068907ba0c9a5b3ef7852/
> sc/source/ui/unoobj/docuno.cxx#3577

Thanks. 
I can't start to study and analyze the complex C++ code (I never understood sufficiently nor ever liked). 

As a frequent user of the API I would, however, expect that things are consistent to a degree allowing for a sufficient understanding either by a kind of self-explanation and educated reasoning or by well structured documentation. 

That there are objects of different types in a sense as underlying the above example without giving the user reliable information about it is just confusion, imo. 

I'm told that only service names are assured to be stable. OK. But if so there must be a service helping to distinguish "different object types" in every case. Otherwise implementation names must get assured stability, and must be applied in a way offering the mentioned functionality. 

Also a kind of bundling or "merging" services in a way that results in facts like EqualUNOobjects(cellObject, cellObject.Text)=True (same "object type"?) is evil if not at least there are reliable means to make the needed distinctions in a different way. 

An API will always partly be useless or create errors if its usage requires full understanding of the core code. 

If "object types" are actually defined by their BUNDLING of services, these types must have stable names, and their bundling (including the surprising "identities") must be documented.