Ill-defined programs

I'd like to follow-up on discussion points mentioned in
https://github.com/gpuweb/gpuweb/issues/39:

> There is no duty to detect or report whether an application is actually
ill-behaved. Attempting to do so may incur overhead. For a development
environment it may be desirable to detect bad behaviour, but that is not a
security requirement.
> We don't care about the computed results or performance of an ill-behaved
application. That may be a user-experience concern, but not a security
concern.

This is wider than just shaders or just security, so I'm following up on
email as opposed to hijacking the GitHub thread.

The approach expressed by David matches the direction we (as in - Mozilla)
would like to see WebGPU going: allow the user to fully (*explicitly*)
specify what needs to be done, promise the portability and best performance
for well-defined programs, and secure the ill-defined programs without
going extra mile for making them portable or fast.

It goes somewhat across the Apple's idea that since the browser has to
validate all the API calls (or, in this case, shader code/execution) for
security, it can make detailed decisions on how the work is submitted to
the backend API (e.g. insert pipeline barriers, allocate resource memory,
clamp array indices, etc), thus turning the exposed API to have more
implicit parts.

Trying to figure out the steps to make an objective (non-opinionated) call
to this issue, we can start with these questions:
  1. Are there any objections to lowering portability/performance
guarantees for ill-defined programs?
  2. Are there any objections to having an optional debug validation layer?
  3. Can we agree that API simplicity is lower priority than security
(starting with obvious), portability, and performance?

Thanks,
Dzmitry