Perceived inconsistency with "IndexedDefaultMemberAccess" inspection

[Rsge]

Hey,
I didn't want to submit this as a bug right away, because I'm pretty sure it isn't one and I'm just too inexperienced to understand the logic behind the decision.

So, when I write something like the following:

Private Sub Testing()
    Dim foo As Range
    Set foo = ActiveSheet.Cells(1, 1)
    Dim bar As Range
    Set bar = foo.Cells(1, 1)
End Sub

I get an inspection for an indexed default member access - but only for bar, not foo. So when running code correction, it just adds a .Item after .Cells for bar, not foo:

Private Sub Testing()
    Dim foo As Range
    Set foo = ActiveSheet.Cells(1, 1)
    Dim bar As Range
    Set bar = foo.Cells.Item(1, 1)
End Sub

But why not add the .Item for foo, too?
This code also works:

Private Sub Testing()
    Dim foo As Range
    Set foo = ActiveSheet.Cells.Item(1, 1)
    Dim bar As Range
    Set bar = foo.Cells.Item(1, 1)
End Sub

Furthermore, the same thing happens for assignment of values, e.g. to as String - this produces no inspections:

Private Sub Testing()
    Dim foo As Range
    Set foo = ActiveSheet.Cells(1, 1)
    Dim bar As Range
    Set bar = foo.Cells.Item(1, 1)
    
    Dim str As String
    str = foo.Value
    str = bar.Value
    str = ActiveSheet.Cells(1, 1)
End Sub

while leaving out the .Value for either foo or bar does.

I see that the difference is: Using a variable as a base without the default member generates an inspection, while using native classes and methods doesn't.
But what is the reason for the (perceived) inconsistency in treating these cases?

[MDoerner]

Let me try to explain what I think is the issue here.

This seems to boil down to a peculiarity in the Excel object model. In case you declare your variable as Range, Rubberduck knows that it is a range and that the member Cells has no parameters and just returns the same range with a (potentially) different indexing behaviour. Accordingly, the inspections show up.
On the other hand, the ActiveSheet function has a declared return type of Object; it might return aWorkSheet or a ChartSheet, which is only known at runtime. Because the Object type can have arbitrary members, Rubberduck cannot identify that the Cells member does not have parameters and thinks that the standard assumption of a normal function access applies.

[Rsge]

It seems you are right about Declaration as Range vs. Object being the driving factor - this also doesn't generate the inspection:

Private Sub Testing()
    Dim meow As Object
    Set meow = ActiveSheet.Cells(1, 1)
    Dim woof As Object
    Set woof = meow.Cells(1, 1)
    Dim whinny As Range
    Set whinny = woof.Cells(1, 1)
    Dim peep As Range
    Set peep = whinny.Cells.Item(1, 1)
End Sub

.Item is only suggested for peep, not any other variable here.

Then it probably would be good practice to include the default member access in cases of Objects, too, for consistency's sake?
Meaning if I want to have a simple loop over cell values in a Sheet I've got to do something like the following?

Private Sub Testing()
    Dim wb As Workbook
    Set wb = Workbooks.Open("Path")
    Dim ws As Worksheet
    Set ws = wb.Sheets.[_Default](1)
    Dim i As Long
    i = 1
    Dim j As Long
    Dim currentCell As Range
    Dim foo As String
    Do Until LenB(ws.Cells.Item(1, i).Value) = 0
        j = 2
        Do Until LenB(ws.Cells.Item(j, i).Value) = 0
            Set currentCell = ws.Cells.Item(j, i)
            foo = currentCell.Value
            foo = Replace(foo, " ", vbNullString)
            ' Do other stuff with foo.
            currentCell.Value = foo
            j = j + 1
        Loop
		' Do other stuff per column.
        i = i + 1
    Loop
End Sub