I'm not entirely happy with any of the available options and intend to write my own to rectify the situation.
I feel there's a huge problem in general with Unix shells, which is the whole problem of encapsulation and delimiters is not adequately addressed. Piping between two processes is easy, but getting it right in the corner cases (i.e. spaces in filenames, etc.) is harder. Most of that difficulty could have been avoided if they had made all the tools support the null character as a delimiter, as GNU find and xargs do. Null is almost universally recognized as something that should not (or, in some cases,
can not) appear as a part of a string. But in general I feel that it's important to think about how tools could be made to cooperate better without the need for all this user-directed parsing and re-encapsulation in a pipeline job.
At present I mostly use bash just out of habit. In my search for something better I have looked at mksh and zsh, mostly to see what they have to offer. I like some of the features they offer but still want to come up with something better.
One of my favorite features that I haven't quite found a good use for is ksh coprocesses. It's a little frustrating that the buffer flushing discipline required for coprocs isn't followed by so many of the programs that I might actually want to use as coprocs. It's also a bit annoying that there's just one coproc slot. (You can move the coproc to other file descriptors, but that's another problem with the Unix shell - working with and managing numbered file descriptors is a lousy way to program. They aren't scoped, there's no control over whether they're exported (not that most programs would know what to do with an exported file descriptor anyway), there's nothing to protect you from clobbering one numeric FD with another... At least Bash's named redirection ("command >&{varname}") helps somewhat...