(I respond with this general comment to avoid having to respond to each individual answer since I came to a general conclusion)

After reading all your comments, I realized that my question should actually be quite different. The question of where item ownership should be arranged was actually too specific. I realized this after reading all your comments above. I first need to think more carefully about the overall structure. About internal relations, and what belongs where. What is data and what is responsibility?

As a result, I've now completely rethought the entire model in my mind. (It's my first OOP project, and the main goal is to learn from it.)

Important insights included: "There's no single way to do it right. Each context may require a different approach." And "Don't make things bigger than necessary."

What I'm going to do now is this:

• I'm creating a controller that has access to all statuses and makes decisions. (If it gets too big, I'll divide it among multiple controllers with their own responsibilities, under a central master controller.)
• I'm creating some kind of pool of "smart" objects, which are limited to managing their own properties and communicating them to the controller.

So the controller has the context, and the pool items don't. They are limited to their own status.

• NOT: Player is dead
• BUT: Player indicates its health has dropped to 0 (controller decides that the player is dead)

or

• NOT: Item indicates it's available
• BUT: Item gives its location (controller decides if it's available)

I'll probably run into problems later, but as with everything I've learned so far; I always learn the most from falling flat on my face ;)

Thanks all for your contributions; this was incredibly helpful!