I would expect that is normal.
An index insert method is practically a backing map listener. Listeners only react to change, they are not able to add additional entries to a partition-level operation (lite transaction) they got the event about. Therefore you are not supposed to reference additional entries from the index mutation methods, you are only supposed to work on entries given to you in the event.
Also, I am not sure you are supposed to retain the BackingMapContext in the index.
The places where it is safe to call BackingMapContext.getReadOnlyEntry(), are I believe only entry processors, entry aggregators, map triggers and interceptors handling the BEFORE_ EntryEvents, and then again only for entries on local partitions (i.e. partitions they are operating on).
Hey Robert, and thanks for the response!
I'm not looking to add additional entries to a partition-level operation/mutate the backing map - what I'm after is a viable replacement for the now deprecated backing map access. My code works fine of 3.7.1.x branch. Listeners in previous versions of Coherence could quiet happily access backing maps.
Personally, I can see no reason, conceptually, why getReadOnlyEntry shouldn't work within the index call.
Regarding retaining the BackingMapContext - this is normal, and indeed Coherence's own SimpleMapIndex does the same.