Recent Change in Behavior when Group is (none)

When an object and a parcel both belong to the same group, and the parcel has Group Object Entry set, then the object should be able to move into that parcel with llSetPos or llMoveToTarget.
Well, I discovered several months ago that if a parcel does not have a group, does have Group Object Entry set, and I changed the group of my object to (none) THEN both the group of the parcel and the group of the object became 00000000-0000-0000-0000-000000000000 (which matched) AND my object was allowed to enter the parcel. I swear I tested this and built objects that moved into parcels around mine. But they don't work any more. Has something changed?
I realized at the time that this looked like a great big hole in the security of SL. Lots of people set the group of their property to (none), and lots of people set all the group access bits in their property management dialog (I think this is the default). Not only could my objects enter their land, but usually Group Create Objects is set. This meant that I could use their land as a sandbox. I swear I tried this and it worked. But it doesn't work any more. Has something changed?
I want to sell objects that move around and I want my objects to know where they can safely move to. I used to be able to compare the group of the land with the group of the object, but now there is one case when this doesn't work: When the group of the object and the group of the parcel are both all zeros, this could mean that the owner of both has set all his groups to (none) and the object can safely move. Or it could mean that the object was rezzed by someone that had their group set to (none) but it is trying to move onto land owned by someone else who set the group of their land to (none) but did not set All Residents Object Entry. When the parcel group is all zeros, I no longer know if I should look at the Group parcel flags or the All Residents parcel flags. I didn't used to have this quandary, has something changed?

There have been lots of strange edge cases with groups and land, and LL has been gradually plugging them up.

LSL is loaded with nasal demons. If some behavior is undefined, about the only thing you can expect is that it can change without notice.

Correct. And, all behavior is undefined.

We can only rely on behavior remaining consistent for things where lots of content depends on it, forcing LL's hand.

BTW, this seems consistent with the llSameGroup(id) call, which returns TRUE if the user isn't wearing a group tag and the object's group is None.

But I have no idea if it's a change in behavior.

True. I swear LL is probably the only company (discounting Microsoft, though perhaps they've done a little better of late) with a large API used by a gigantic user base that doesn't have designer generated and maintained library documentation. Absolutely nothing is official. It's a crapshoot whether something is called a defect or an enhancement request. Expected behavior is left up to trial-and-error. The whole system is a gigantic black box to everyone trying to use and document it.

I've proposed since I joined SL that LL actually document their own library API, potentially with user-contributed commentary to help with examples and fill in corner cases to help shape future revisions (with an official adoption process for changes). I guess that's just too professional an approach or something?

Well, it's too late now, Hewee. That train left the station, the horse has already left the barn, and Elvis is no longer in the building. They're stuck with supporting the extant behavior, because so much content now depends on it, and they can't call any behavior "unintended" because it wasn't documented in the first place.

If they did document it, that would just hang another albatross around their necks.

The cat's out of the bag. There's no use crying over spilled potion. The cat's among the pixies.