Yeah, I think I largely expect that... we're splitting the API in two: we want to keep the methods we historically defined, with their historical behaviours and returns, for external users... and then we must have whatever methods we require internally. Those will naturally be very similar at the moment, because the "external" methods were originally defined based on our internal needs.

BTW, we should probably be explicitly tagging the "old-and-new-again" methods with `:api: plugin`, or whatever spelling is currently appropriate (@rafaelfranca?), to remind our future selves that's why they're here: unlike the new properly-internal ones, we should aim to preserve them through any refactoring. (Or do we need a different doc category, for "we don't promise a deprecation cycle, but we'll make a best-effort attempt to maintain this"?)