I’m thinking about deny or at least discourage its use since the very start because the e combined with s/// allows to manipulate the output freely like in a shell-script. We already have the bash track and I don’t know if another track with this feature would be a good idea. Anyway, I don’t know about other tracks either, many languages can also manipulate the output of shell commands.
All practice exercises I have committed until now don’t invoke shell commands in their examples but “vetoing” the use of the e command has its drawbacks, like:
sed is too slow for math.
I have removed some tests with “big numbers”, float point numbers are “big numbers” too for sed.
without e command, the number of possible solutions are reduced.
Exercises like grains are unfeasible with pure sed but easy with sed + bc like in: s/.*/bc <<< '& + &'/e.
People are welcome to solve things however they want. Some solutions may not be in the spirit of the exercise/track, but that’s fine; people get out of exercises whatever they choose to put in. The choice is theirs.
The interpreter doesn’t have this kind of feature. To implement something like this I’ll need an external tool (or write one) to parse sed script and fail if it found an e command.
In the “real world” people ideally use the most appropriate tool for the task and someone fluent in sed is often familiar with a whole lot of tools. If you need to do math, you should use the most appropriate tool for doing math. But the exercise tracks aren’t about solving a specific problem; they are about getting better at a specific language.