Of course, our understanding and suggestions are relatively high-level and abstract at this point. If an open-source version becomes available, we will have more valuable insights as we will be able to take a closer look and use it. Please see below:

> The ability to enable/disable the feature in parts of the program.

Currently, I've added an attribute that allows developers to opt-out of the check, along with specifying functions and namespaces to omit through the commandline. Is there some better way to do this?

Sounds sufficient for an MVP.

> The ability to include/exclude certain checks for a given run of the analyzer.

What do you mean exactly by that? Like, exclude use-after-move, but have the others? Or more broad, exclude the borrow checker, but have the lifetime?

Ideally, both. As more types of analysis are added to such a solution, people would benefit from a more fine-grained set of checks. This way, one can, for example, turn on one check and refactor code, then proceed to the next check. This makes it more usable than trying to correct the results of many checks all at once, especially in a large codebase.

> Good to have: It would be useful to be able to restrict the subset even more than the default “safe subset” by enabling specific criteria. For example, a feature, e.g., goto, could be controversial and not be excluded from the “safe subset,” but a user could exclude it in their own sub-"safe subset”. Or, it could be versioned, or, modularized.

I think this is a very nice and neat idea, though I have no idea how to (realistically) do this.

Perhaps one option would be to have a “core” safe subset, let’s say the most strict set. Then, define “modules” that, when added, extend the core. Consider RISC-V, with its modular design, a “base” with “extensions.” While the base itself can implement a fully functional computer, extensions add additional features without conflicting with one another.