The shell was isolating the user from the exec error by always existing and turning the exec error into a status return.

>>> subprocess.run('foo', shell=True)
/bin/sh: line 1: foo: command not found
CompletedProcess(args='foo', returncode=127)
>>> subprocess.getstatusoutput('foo')
(127, '/bin/sh: line 1: foo: command not found')

For things that don't actually _need_ the output as a pipe file (such as your .read() example), I recommend using .run() like that today and accessing the .stdout and .returncode attributes of the CompletedProcess.  Or use the old getstatusoutput() API if you don't mind stderr being included.

As far as new APIs go, yet another keyword only argument to subprocess.POpen's existing huge list that tells it to turn exec failures into a particular returncode value could be added as a feature.  Is this use case compelling enough to do that?

...

As far as distinguishing failures go, I suggest making such an API be to allow the user to specify a non-negative int to use as returncode - a unique int or one that is out of range such as a negative number or large number could be used to distinguish things if the user were so inclined or even an int subclass like True or an IntEnum value.  But lets keep it a non-negative int, not an arbitrary object.  Negative ints map to signals; using those would be confusing for CalledProcessError when a check constructs one.

```
>>> subprocess.run('foo', exec_fails_via_returncode=256)
CompletedProcess(args='foo', returncode=256)
```

With a default of exec_fails_via_returncode=None being the existing exception raising behavior.

That isn't joyful to use as an API.  So I don't expect most people would use it directly.  They'd have a wrapper function.  Ie: just another variation on getstatusoutput() that allows for use of a shell or stderr inclusion to be controlled.

The shell is fast.  I'd just use the shell when replacing os.popen uses in tests.