Because ReturnToVTPool doesn't recursively do the same for applicable field member's, it's easy to make a nasty mistake:

message Foo {
  option (vtproto.mempool) = true;

  repeated Bar bars = 1;
  repeated Baz bazs = 2;
}

message Bar {
  option (vtproto.mempool) = true;
}

message Baz {
  option (vtproto.mempool) = true;
}

for _, mm := range foo.Bars {
	mm.ReturnToVTPool()
}
for _, mm := range foo.Bazs {
	mm.ReturnToVTPool()
}

// Whoops — this does ResetVT() on things that may have been picked up from the pool already.
foo.ReturnToVTPool()

Rearranging the order doesn't help because the parent's slices are reset. The only ways to do this safely at the moment are:

• Copy the slices first, return the parent, then return the children.
• Do defer mm.ReturnToVTPool() inside the loops.
• Attach finalizers to child messages that return to the pool, release the parent only, and rely on best-effort release.

Leaving up to you all if this requires code or documentation clarity — I'm not sure if this is intended for explicitness when dealing with pooled objects. But having some method of release recursively would make it much less error prone.