Yeah, it looks to me as though the difference is in the routine for calculating what a non-player thing can see and what a player can see. From Appendix B (this is a few Inform versions ago but I think still current):
§7. Visibility Parent. The idea of VisibilityParent is that it takes us from a given position in the object
tree, o, to the next visible position above. Note that
(1) A container has an inside and an outside: this routine calculates from the “inside of o”, which is why it returns nothing from an opaque closed container;
(2) Component parts are (for purposes of this routine) attached to the outside surface of a container, so
that if o is part of a closed opaque container then the visibility parent of o is its actual parent.
§9. Scope Ceiling. Scope is almost the same thing as visibility, but not quite, and the following routine
does not quite duplicate the calculation of FindVisibilityLevels. The difference arises in the first step, where we take the parent of pos, not the core of the parent of the core of pos: this makes a difference if pos is inside a container which is itself part of something else.
VisibilityParent is the first step in the calculation of FindVisibilityLevels.
I think what this means is:
When there’s a rock on the lid and the player is in the location, whether the player can see the rock is determined by using VisibilityParent for the rock, which uses a relation that (per an earlier comment in Appendix B) contracts together all nodes in the object tree where one thing is a component of another. So it goes rock → lid → room, skipping over the dumpster since the lid is part of it.
When the player is on the lid and the rock is in the room, the player’s visibility is determined by using ScopeParent, which doesn’t skip parts in this way. So it goes player → lid → dumpster and stops there, since the dumpster is closed and opaque.
You can also see that if you give the player a light source and go onto the lid, the room description heading becomes “The Dumpster” and the player can’t see anything in the room.
I’m not sure why it should be like this, though? Enterable containers that are part of things seem to get messed up, unless I coded it wrong:
Alley is a room. A pickup truck is in Alley. A bed is a closed openable opaque enterable container. The bed is part of the pickup truck.
The player carries a rock and a torch. The torch is lit.
yields
Alley
You can see a pickup truck here.
>open bed
You open the bed.
>put rock in bed
You put the rock into the bed.
>close bed
You close the bed.
>look
Alley
You can see a pickup truck here.
>open ed
You can't see any such thing.
>open bed
You open the bed, revealing a rock.
>look
Alley
You can see a pickup truck here.
>take rock
Taken.
>drop it
Dropped.
>enter bed
You get into the bed.
>look
Alley (in the pickup truck)
You can see a rock here.
>close bed
You close the bed.
>look
Alley (in the pickup truck)
You can see a rock here.
>showme me
yourself - person
torch
location: in the bed , which is part of the pickup truck in Alley
singular-named, proper-named; unlit, inedible, portable; male
list grouping key: none
printed name: "yourself"
printed plural name: "people"
indefinite article: none
description: "As good-looking as ever."
initial appearance: none
carrying capacity: 100
>out
You can't get out of the closed bed.
At the end when I’m in the closed bed, I shouldn’t be able to see the rock and the Alley shouldn’t be the visibility ceiling, it seems.
EDIT: Curiouser and curiouser:
>look
Alley (in the pickup truck)
You can see a rock here.
>get rock
You can't see any such thing.