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?