What is the Problem Being Solved?

#1725 is one way to provide the ability to opt out of strict Exo object method guards. It would be nice for even finer granularity to be able to express the code's intentions more accurately.

Description of the Design

As a jumping-off point for better designs, here is a (probably suboptimal, may not be easily implemented), but conceptually simple one:

1. For convenience of a library user, provide an "unprotected: true" Zone option that does not enforce any exo interfaces for exos created in that Zone.
2. For patterns, method guards, and interface guards, provide an operator that designates any such context as "unprotected", such as:

// Return a pattern of the same type as T but always matches its value, regardless of passability.
M.unprotected(pattern: T);
// Return a method guard that passes through all values, uninspected.
M.unprotected.call(...args).optional(...opts).rest(dots).returns(ret);
// For every method in methodGuards, mark that method's arguments and return type as unprotected.
M.unprotected.interface('NameI', { ...methodGuards }, flags);

As a possible enhancement, do the work so that individual M.unprotected(patt) annotations can be used to mark specific arguments (or the return value) as unprotected.

Security Considerations

The use of unprotected needs to be clearly visible to prevent accidentally overlooking the absence of guards for a given method or argument.

Scaling Considerations

May somewhat complicate the implementation, but may also save time checking passStyleOf.

Test Plan

n/a

Upgrade Considerations

n/a