Ownership with a physical representation

After reading on RAII, viewing Herb Sutter's CppCon2014 presentation, and reading the core guidelines and related articles over the course of some days, I'm still quite confused on ownership and related semantics.

Let's say class A and class B represent physical entities, and there's a Scene class and a Process class. The Process class is a main function, if you will. In the real world, an A can acquire a B and physically keep it for itself. It can also release it. During the course of a Process instance, an A object must therefore be able to have for itself a B instance, and also to release it after it's done with it. As and Bs live in a Scene, which a Process must manage.

Also B is derived: an A uses some interface, while a Scene uses some other interface a B provides.

Let's try with some code for at least the Process:

class Process
{
public:
  void run();
};

void Process::run()
{
  auto scn = Scene {};
  auto a = A {};
  auto b = B {};

  scn.add(a);  // stores a
  scn.add(b);  // stores b

  a.acquire(b);  // stores b, and represents physical possession of a B
  a.doSomething();
  a.release(b);  // sets a's B instance to null, and physically loses the B
}

Correct me here if I'm wrong, this is the dubious part.

From what I understand, A should (instead of like the code) be on the heap and pointed to from a shared_ptr, since the Process and the Scene both have their own instance of A. The same would happen for B, which is stored both in a and in scn, and which is in process. Why would then scn not be make_uniqued?

The other way to do this is have everything on the stack (like in the code snippet). Both solutions seem identical to me, I don't understand the semantic difference of these two options at all, but I would tend to the first one.

C++ ownership essentially boils down to "who is responsible for deleting this particular object were they to die at this particular moment". In your example, as all objects have automatic lifetime, all of them are owned by Process::run itself. There's no ownership transfer involved in any of add, acquire or release.

Now, what about the same thing with dynamic-lifetime objects? Your description (where I assume by C you mean Scene) can be implemented in two different ways still:

Scene holds std::unique_ptrs to A's, that's a given
Scene and A can hold either std::unique_ptrs or std::shared_ptrs to B.

The choice in the second bullet can be made through the definition of ownership I outlined above. What happens when and A dies while holding a B?

If the B should die as well, then A is its sole owner and should hold it via std::unique_ptr
If the B should remain inside the Scene, then Scene and A are both owners, and should both hold the B through a std::shared_ptr

This doesn't include non-owning (raw) pointers, which can be useful (for example, if A owns a B but Scene still needs a direct reference for whatever purpose). These must be updated separately.