There's no law stating every $SHELL has to be POSIX compliant... one runs a different shell because they lean towards a different idiom.
I absolutely encourage that! I accepted that possibility in my comment. See the kind of stuff I build: https://github.com/akkartik/mu. I introduced Posix purely as an example that builtins are as subject to standardization as coreutils.
Other than clarifying that I'll agree to disagree. It's great to rethink a shell from the ground up. If you're doing that, what earlier shells happen to choose as a builtin is an irrelevant signal. Depending on how you design your idioms, it may make sense to override stuff from coreutils as builtins. As you've pointed out, such overriding has already happened in bash and other shells.
These are all artificial boundaries to be questioned. Decide what behavior you want to copy and what you want to rethink regardless of where you find it.
Sorry but now it's my turn to not understand the point raised. Are you arguing that people should be allowed to explore other options outside of POSIX compliance but except in this specific case?
It's pretty clear this shell isn't intended to follow in the footsteps of Bash, let alone be fully POSIX compliant, so I don't really understand why you are comparing it to them in terms of compatibility (and even more confused now that you've said you encourage people breaking POSIX).
Or is the point you're raising a question of what should be a builtin and what should not?
(happy to agree to disagree by the way; but I'm just a little confused as to what we are disagreeing about :))
Set aside my mention of POSIX as a minor point. My basic claim is this: building a whole new shell is an ambitious act. Whether your goal is to create a better experience for others or just learn new skills, restricting yourself to what earlier shells happen to consider to be builtins is limiting ambition. Be more ambitious and rethink as much as you want.
I'm not saying you have to rethink everything all at once all the way up from machine code (though I'm sympathetic to and experienced in that particular failure mode ^_^). I'm saying if you have an idea to improve 'cat' to fit better with your new shell, the fact that it's in coreutils shouldn't cause you pause. Who cares if it's a builtin in bash or not? Make it a builtin in your shell.
I absolutely encourage that! I accepted that possibility in my comment. See the kind of stuff I build: https://github.com/akkartik/mu. I introduced Posix purely as an example that builtins are as subject to standardization as coreutils.
Other than clarifying that I'll agree to disagree. It's great to rethink a shell from the ground up. If you're doing that, what earlier shells happen to choose as a builtin is an irrelevant signal. Depending on how you design your idioms, it may make sense to override stuff from coreutils as builtins. As you've pointed out, such overriding has already happened in bash and other shells.
These are all artificial boundaries to be questioned. Decide what behavior you want to copy and what you want to rethink regardless of where you find it.