Not sure this is a bug, but I was a little surprised by the char position
reported by --sandbox errors when there's an s///e command present. (gnu
sed 4.8 via nixpkgs on macOS)

By 1-indexed position, 9 is correct for all 3 commands below, but the last
two indicate 10 and 11 respectively:

$ sed --sandbox -e '{ s/b/c/z }'
sed: -e expression #1, char 9: unknown option to `s'

$ sed --sandbox -e '{ s/b/c/e }'
sed: -e expression #1, char 10: e/r/w commands disabled in sandbox mode

$ sed --sandbox -e '{ s/b/c/e ; s/b/c/e }'
sed: -e expression #1, char 11: e/r/w commands disabled in sandbox mode

It looks like the s command has to be fully consumed before the sandbox
check fails, leaving the error at whatever position technically terminated
the s command?

T