If your workflow is like:
1. Manipulate current directory
2. Run some program
3. Manipulate current directory again
4. Run yet another program...
You can actually consider current directory as immutable already.
It became "badly mutable" for example if you manipulate the current directory and this change is observable from a program point of view which is already running. Would that be really useful?
To clarify I am not trying to say that absolutely everything should be immutable but it's fun thought experiment how far you can go.
I don't see how. The suggestion was to use a Haskell-like scripting language for interactive use on the command prompt. Note, we're not talking about apps that run from that prompt; we're talking about the shell itself. And all shells today have mutable global state in form of current directory (and pushd/popd stack, usually).
Shell is kind of REPL (read–eval–print loop). In OOP you use looping with mutation and in FP you use recursion. This may not sound very informative but still: "Just fold over inputs, what's the problem?".
Being immutable doesn't mean that everything is static but that things aren't changeable in place. So instead of having a global mutable state, you have this local state which you can alter by creating new instances and passing them around. In the end, the difference is that on what scope changes are observable and how that constraint effects on your design. In some sense: mutable = changes are uncontrollable, immutable = changes are controllable.
You can actually consider current directory as immutable already.
It became "badly mutable" for example if you manipulate the current directory and this change is observable from a program point of view which is already running. Would that be really useful?
To clarify I am not trying to say that absolutely everything should be immutable but it's fun thought experiment how far you can go.