getMethodGuardPayload = methodGuard => {
  if (matches(methodGuard, MethodGuardShape)) {
    return methodGuard.payload;
  }
  mustMatch(methodGuard, LegacyMethodGuardShape, 'legacyMethodGuard');
  const {
    // @ts-expect-error Legacy adaptor can be ill typed
    klass: _,
    // @ts-expect-error Legacy adaptor can be ill typed
    callKind,
    // @ts-expect-error Legacy adaptor can be ill typed
    returnGuard,
    // @ts-expect-error Legacy adaptor can be ill typed
    restArgGuard,
  } = methodGuard;
  let {
    // @ts-expect-error Legacy adaptor can be ill typed
    argGuards,
    // @ts-expect-error Legacy adaptor can be ill typed
    optionalArgGuards,
  } = methodGuard;
  if (callKind === 'async') {
    argGuards = argGuards.map(adaptLegacyArgGuard);
    optionalArgGuards =
      optionalArgGuards && optionalArgGuards.map(adaptLegacyArgGuard);
  }
  const payload = harden({
    callKind,
    argGuards,
    optionalArgGuards,
    restArgGuard,
    returnGuard,
  });
  // ensure the adaptation succeeded.
  mustMatch(payload, MethodGuardPayloadShape, 'internalMethodGuardAdaptor');
  return payload;
}
By using this abstraction rather than accessing the properties directly,
we smooth the transition to https://github.com/endojs/endo/pull/1712,
tolerating both the legacy and current guard shapes.

Unlike LegacyAwaitArgGuardShape, tolerating LegacyMethodGuardShape
does not seem like a currently exploitable bug, because there is not
currently any context where either a methodGuard or a copyRecord would
both be meaningful.

@param {MethodGuard} methodGuard
@returns {MethodGuardPayload}