Why would I use .namespace.myvar?

Why would I use .namespace.myvar?

[Stephane Chazelas]

(not sure which of zsh-users or zsh-workers is best suited for
this discussion, I'm picking zsh-users for now but please feel
free to move to zsh-workers in follow-ups).

I didn't read the initial discussions around the introduction of
namespaces in the current development version of zsh, but from
what I can tell it means:

- "." can now be used in the name of a variable, though with
  limitations:
  * .foo, foo., a.b, .a.b, a.1, .a.1x are OK, but not
  ..foo, .foo., .1.a, foo.., a.b.c, .a.b.c
  * you can refer them as ${a.b}, but not $a.b (understandably)

- the ones starting with . (and not having them starting with .
  is discouraged, presumably because that would conflict with
  ksh93's compound variables which zsh might want to support in
  the future?) are hidden from the output of "set"/"typeset"

  and there's no way to unhide them even with typeset -h, except
  with things like:

  typeset -p ${(kM)parameters:#.*}

It's always been possible to use . (or any character or
non-character, even the empty string) in function names, so
functions are not covered in the new feature.

And unless I'm missing something, that's it.

In particular, as noted in the doc, there's no support for
ksh93's:

$ namespace foo { a=1 b=2 c=3; }; echo "${.foo.a} ${.foo.b} ${.foo.c}"
1 2 3

So why would I use a ${.mynamespace.myvar} over
$_mynamespace_myvar, $ːmynamespaceːmyvar or $𐅂mynamespace𐅂myvar
(which do work on GNU systems at least as ː, 𐅂 as well as
hundreds of other characters which look appropriately shaped for
the purpose are classified as alpha (in locales whose charmap
have them) there) for my variables which I would want namespaced?

AFAICT, that doesn't give me more guarantee of avoiding clashes,
and that means I have to use those braces.

I could also hide my _mynamespace_myvar variable with typeset
-h if I wanted to.

Is there a chance that ksh93's namespace keyword be added in the
future? Would the fact that function names have been allowing .
since forever or that .foo or .foo.1 are allowed not be a problem?
How about nested namespaces?

Is using ${.foo.bar} going to be recommended going forward for
namespacing variables in user-contributed code shipped with zsh?
Is the intention to reserve those for code included with zsh to
users can be sure not to clash with the zsh ones if they don't
use them?

Thanks
Stephane
 

Re: Why would I use .namespace.myvar?

[Bart Schaefer]

On Sat, Mar 9, 2024 at 6:30 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> (not sure which of zsh-users or zsh-workers is best suited for
> this discussion, I'm picking zsh-users for now but please feel
> free to move to zsh-workers in follow-ups).

For -users who haven't been following the -workers list, namespaces
are a new feature appearing in the next release (version number TBD).

Reordered some excerpts below to group responses better ...

> - "." can now be used in the name of a variable, though with
>   limitations:
>   * .foo, foo., a.b, .a.b, a.1, .a.1x are OK, but not
>   ..foo, .foo., .1.a, foo.., a.b.c, .a.b.c
>   * you can refer them as ${a.b}, but not $a.b (understandably)

So far so good.

> - the ones starting with . are hidden from the output of "set"/"typeset"

Yes.

>   (and not having them starting with .
>   is discouraged, presumably because that would conflict with
>   ksh93's compound variables which zsh might want to support in
>   the future?)

Something like that.  Ksh has a couple of special meanings of
${var.func} in addition to compound variables.  It's all rather messy
if you ask me, but we might pick and choose.

>   and there's no way to unhide them even with typeset -h

That's also correct, except that -h doesn't mean the same thing at
all, so it's not really a meaningful "even with".

> except with things like:
>
>   typeset -p ${(kM)parameters:#.*}

Also "typeset -pm pattern"

> It's always been possible to use . (or any character or
> non-character, even the empty string) in function names, so
> functions are not covered in the new feature.

Also correct.

> In particular, as noted in the doc, there's no support for
> ksh93's:
>
> $ namespace foo { a=1 b=2 c=3; }; echo "${.foo.a} ${.foo.b} ${.foo.c}"
> 1 2 3
>
> Is there a chance that ksh93's namespace keyword be added in the
> future?

Yes, adding the namespace keyword is planned, probably for a
next-after-next release when we have some more real-world usage of the
current code.

> So why would I use a ${.mynamespace.myvar} over
> $_mynamespace_myvar, $ːmynamespaceːmyvar or $𐅂mynamespace𐅂myvar
[...]
> for my variables which I would want namespaced?
>
> I could also hide my _mynamespace_myvar variable with typeset
> -h if I wanted to.

The -h option of typeset does not hide the name, it hides the
"specialness" of a parameter.  If you apply it at the top level (which
most autoloaded specials do), then in order to make a local with the
same properties you must do e.g.
  typeset +h parameters
to get a local that behaves like the global autoloaded $parameters
association.  If there's a global special like $status that does not
use -h, then
  typeset -h status
gives you a local that doesn't mirror the global.

The -H option hides the value, but does not hide the name.  So only
using a namespace hides the whole thing.

> AFAICT, that doesn't give me more guarantee of avoiding clashes,
> and that means I have to use those braces.

Given dynamic scoping, the only thing that really comes close to a
guarantee of avoiding clashes is zsh/param/private, so that is true.

> Would the fact that function names have been allowing .
> since forever or that .foo or .foo.1 are allowed not be a problem?

There's a small chance of backward-compatibility issues if someone is
using function names beginning with a dot, yes.  Names containing a
dot are only an issue if the part before the dot is the same as the
name of a parameter

We'd have to make some decisions about .foo.1 and similar with respect
to assignments -- it's not a large problem for expansions given that
  namespace foo { echo $1; }
"fails upward" to the positional parameter $1 if ${.foo.1} does not exist.

> How about nested namespaces?

They don't work / aren't allowed.  Each "namespace" keyword starts a
new global namespace even if used inside another namespace
declaration.

> Is using ${.foo.bar} going to be recommended going forward for
> namespacing variables in user-contributed code shipped with zsh?

Probably only for user-contributed code that needs to maintain global
state for re-entrancy, but I wouldn't expect it to be more than a
recommendation.

OTOH for example Oliver is already doing that.

> Is the intention to reserve those for code included with zsh to
> users can be sure not to clash with the zsh ones if they don't
> use them?

It's the intention to reserve some namespaces, the way ksh reserves
the ".sh" namespace, yes.  So far there's only been minimal discussion
of which names would be included.  Possibilities are things like
".zsh", ".zle", ".compsys".  The mkshadow (_shadow) utility has
already co-opted ".shadow", and Oliver's "hlgroup" module is using
".zle".

Re: Why would I use .namespace.myvar?

[Stephane Chazelas]

2024-03-09 14:58:10 -0800, Bart Schaefer:
[...]
> >   (and not having them starting with .
> >   is discouraged, presumably because that would conflict with
> >   ksh93's compound variables which zsh might want to support in
> >   the future?)
> 
> Something like that.  Ksh has a couple of special meanings of
> ${var.func} in addition to compound variables.  It's all rather messy
> if you ask me, but we might pick and choose.

Thanks Bart for the detailed feedback!

Yes, all of the namespace, compounds, types, disciplines, nested
assoc/array in ksh93 give an "experimental" vibe and of being
unfinished and/or not fully thought through.

A lot of it is also not hugely useful in a shell, and is not
documented much and I don't expect many people have used even
half of it which likely also explains why it's still quite bogus.

I've just raised https://github.com/ksh93/ksh/issues/727 this
morning about "echo" not working in namespaces making me
thinking there can't be many people using those namespaces there
(even if we take into account that "print" is preferred over
"echo" in ksh)

See also https://github.com/ksh93/ksh/issues/325 and more
generally
https://github.com/ksh93/ksh/issues?q=is%3Aissue+is%3Aopen+namespace
there.

[...]
> That's also correct, except that -h doesn't mean the same thing at
> all, so it's not really a meaningful "even with".
> 
> > except with things like:
> >
> >   typeset -p ${(kM)parameters:#.*}
> 
> Also "typeset -pm pattern"

Thanks, that makes it significantly easier to list variables in
a namespace.

[...]
> > Is there a chance that ksh93's namespace keyword be added in the
> > future?
> 
> Yes, adding the namespace keyword is planned, probably for a
> next-after-next release when we have some more real-world usage of the
> current code.
[...]
> > Would the fact that function names have been allowing .
> > since forever or that .foo or .foo.1 are allowed not be a problem?
> 
> There's a small chance of backward-compatibility issues if someone is
> using function names beginning with a dot, yes.  Names containing a
> dot are only an issue if the part before the dot is the same as the
> name of a parameter
> 
> We'd have to make some decisions about .foo.1 and similar with respect
> to assignments -- it's not a large problem for expansions given that
>   namespace foo { echo $1; }
> "fails upward" to the positional parameter $1 if ${.foo.1} does not exist.

Would it be correct to say that the main goal for introducing
namespaces then would be to tidy-up the output of typeset -p/set
for all the subsystems of zsh written in zsh (completion,
zle...) and third party plugins?

Wouldn't having the .space.var variables and namespace {...} in
two separate releases be counter-productive as plugin authors
would first change their code from:

myplugin() {
  myplugin_myglobal=whatever
  ...
}

To:

myplugin() {
  .myplugin.myglobal=whatever
  ...
}

in 6.0 (say) as an improvement to limit the typeset output
pollution.

Only to change it again to:

myplugin() namespace myplugin {
  myglobal=whatever
  ...
}

(or however namespace is going to be meant to be used then)

In 7.0

(and possibly have to maintain 3 versions for zsh 5, 6, 7).

If it's going to be done in a staged way, it seems it would be
safer to start strict and relax later rather than the other way
round to limit the risk of breaking backward compatibility in
the future.

Like if we allow ${.space} and ${.space.1} now but we find that
it prevents adding namespace {...} in the future, it will be
harder then to say "oh you can't do that anymore".

Deferring the introduction of the "namespace" keyword (which
sounds to me like it's the key missing part for the feature to
be really useful) sounds risky unless we already have a clear
idea of how it's going to work as we might find that the whole
design and possibly user API would need to be rethought (like
the namespaces would need to be declared in advance like in
ksh93).

(having said that, I've not given it much thought myself so my
apprehensions may very well be baseless).

-- 
Stephane

Re: Why would I use .namespace.myvar?

[Bart Schaefer]

On Sun, Mar 10, 2024 at 5:14 AM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> 2024-03-09 14:58:10 -0800, Bart Schaefer:
> [...]
> > > except with things like:
> > >
> > >   typeset -p ${(kM)parameters:#.*}
> >
> > Also "typeset -pm pattern"
>
> Thanks, that makes it significantly easier to list variables in
> a namespace.

I note in passing that "typeset -pm" does unexpected things if the
GLOBALEXPORT option is NOT set ... I'll start another -workers thread
when I have a better idea what's going on.

> Would it be correct to say that the main goal for introducing
> namespaces then would be to tidy-up the output of typeset -p/set
> for all the subsystems of zsh written in zsh (completion,
> zle...) and third party plugins?

No, actually, my main goal for introducing namespaces was to be able
to write the zsh/ksh93 module, and because lack of parameter names
containing a dot has popped up several times (at widely scattered
intervals) over the past multiple years.  "Invisible" parameters was
an unexpected benefit, I didn't even know ksh did that until I was
mostly done with the rest.

It would be nice to make function names starting with a dot
"invisible" as well, but that needs wider discussion.

> Wouldn't having the .space.var variables and namespace {...} in
> two separate releases be counter-productive [for] plugin authors

I'm a little more concerned with internal uses like zsh/hlgroup than
with shell-code plugins.  After all if you've once changed shell code
to use .myplugin.myglobal there's no requirement to rewrite it with
"namespace".  And you can do something along the lines of:

   typeset -g .myplugin.myglobal .myplugin.otherglobal
   typeset -nu mygobal=.myplugin.myglobal otherglobal=.myplugin.otherglobal
   myglobal=whatever
   otherglobal=something

and then replace those two typesets with "namespace myglobal { ... }" later.

Implementing the "namespace" keyword means a bunch of fairly deep
changes, including adding more wordcode elements as the output of new
parsing routine besides figuring out the logic for inserting the
current namespace (at both definition and expansion) and trying again
without it (at expansion).  I'm not (yet at least) familiar enough
with the wordcode implementation to attempt the first part, and I'd
rather have any kinks worked out of the underlying syntactic
implementation before trying the rest.

> Like if we allow ${.space} and ${.space.1} now but we find that
> it prevents adding namespace {...} in the future, it will be
> harder then to say "oh you can't do that anymore".

There shouldn't be any clash with ${.space} because anything declared
with the "namespace" keyword will get dots both before and after.  If
you attempt either of

  namespace newspace { .space=value }
or
  namespace newspace { .otherspace.place=value }

-- I believe (given the ban on nested namespaces) that both of those
would simply skip prefixing with ".newspace." during
assignment/reference.

The potential clash with ${.space.1} is in practice I think also a
non-issue, because ksh doesn't allow a direct assignment "1=one"
anyway, so there's no incompatibility in declaring positional
parameters exempt from auto-prefixing the same way that ${.space} is
exempt.  If you want ${.space.1} you have to always write that out.

There are a bunch of questions to be resolved about how namespaces
actually work.  Ksh doc says "Commands and functions ... that modify
variables or create new ones, create a new variable" -- does "modify"
there mean that if I do --

  namespace foo { PATH="/usr/local/bin:${PATH}"; }

-- that I now have a (useless, as it doesn't affect path search?) new
global variable ${.foo.PATH}?  Alternately, does that mean that we now
have to alter the environment PATH by copy of ${.foo.PATH} and restore
again, on every entry/exit of any subsequent "namespace foo" block?

What about locals?  Do they get auto-prefixed with the namespace too?
What about:

  inner() { local foo; bar=$1; ... }
  namespace outer { inner whatever; ... }

Is "inner" now implicitly using ${outer.foo} during that call?  Did it
create global ${.outer.bar} rather than (as the writer of "inner" may
have expected) creating an actual global ${bar}?  How could the writer
of "inner" protect the function from this effect?  E.g., would/should
using "typeset -g bar=$1" be different?

Given all this uncertainty and that we're already more than 2 years
past the 5.9 release, I'd rather get the tractable parts out there
sooner.

Re: Why would I use .namespace.myvar?

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]



On 2024-03-10 13:08, Bart Schaefer wrote:

> Given all this uncertainty and that we're already more than 2 years
> past the 5.9 release, I'd rather get the tractable parts out there
> sooner.
I thought I'd be able to pick it up as the thread progressed, but I 
still have no idea what a namespace even is.  It sure sounds 
complicated.  I keep seeing structures because of the dots but I know 
that's not the case.  In a sentence or two, what is a namespace and why 
do we want it?  But I do remember vaguely that I once had a question 
where the future solution was going to be just that.  BTW interesting to 
learn that ksh is still in active development, I thought it was on ice, 
like bash.

[-- Attachment #2: Type: text/html, Size: 1353 bytes --]

Re: Why would I use .namespace.myvar?

[Lawrence Velázquez]

On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote:
> BTW interesting 
> to learn that ksh is still in active development, I thought it was on 
> ice, like bash.

Neither is "on ice".  Both are quite active.

https://github.com/ksh93/ksh/commits/dev/
https://git.savannah.gnu.org/cgit/bash.git/log/?h=devel

-- 
vq

Re: Why would I use .namespace.myvar?

[Bart Schaefer]

On Sun, Mar 10, 2024 at 3:16 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> In a sentence or two, what is a namespace and why do we want it?

Quoting the updated FAQ file:

2.9: What is a `namespace' anyway?

  As of this writing, namespaces in zsh are little more than syntactic
  sugar for grouping related parameters.  For example, as of the update
  to PCRE2, the parameters ${.pcre.match} and ${.pcre.subject} are used
  for regular expression substring capture.  The `.pcre.' part is
  the namespace, and when you refer to a parameter that has one, you
  *must* use the `${...}' braces around the name.  Assignments
  are not special, they have the form `.nspace.var=value' as usual.

  Parameters using a namespace have the additional property that, like
  file names beginning with a dot for globbing, they're hidden from
  `typeset' output unless explicitly asked for.

Re: Why would I use .namespace.myvar?

[Ray Andrews]

On 2024-03-10 15:45, Lawrence Velázquez wrote:
> On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote:
>> BTW interesting
>> to learn that ksh is still in active development, I thought it was on
>> ice, like bash.
> Neither is "on ice".  Both are quite active.
Not that I'm in the loop, but I recall some time back, there was an 
exploit in bash and the talk was that there was no one available to fix 
it.  Then I heard that bash development was down to one guy, namely 
Chet.  Mind ... looking at your link, it seems he's quite active, so 
thereyago.  Thanks.  It's healthy.  I know zsh has taken huge 
inspiration from ksh, so having those dudes 'competing' is good for 
everybody.

>
> https://github.com/ksh93/ksh/commits/dev/
> https://git.savannah.gnu.org/cgit/bash.git/log/?h=devel
>

Re: Why would I use .namespace.myvar?

[Ray Andrews]

On 2024-03-10 15:48, Bart Schaefer wrote:
> On Sun, Mar 10, 2024 at 3:16 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> In a sentence or two, what is a namespace and why do we want it?
> Quoting the updated FAQ file:
>
> 2.9: What is a `namespace' anyway?
Sorta like a first name and a last name for a variable?  Even I have 
often run into name crowding.  Just recently there was that grief about 
an unrealized existing integer making mischief.  So 'family names' could 
sure be a good thing.
>
>    As of this writing, namespaces in zsh are little more than syntactic
>    sugar for grouping related parameters.

Re: Why would I use .namespace.myvar?

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote:

>  BTW interesting to learn that ksh is still in active development, I
> thought it was on
>  ice, like bash.


Around twenty years ago, AT&T moved ownership of ksh to their open source
arm, the AT&T Software Technology group (AST), which maintained it as an
open project on GitHub. As with prior releases, the year of the major
release (and corresponding edition of the book) was kept as the "major
revision" number, while subsequent releases incremented an alphabetic
suffix. The last AST release was 93u, released in December 2012 - the 23rd
release of the 1993 version of ksh.  After that the codebase was dormant
for a while.  Then in 2019 a developer got excited about reviving the
project and updating it. They started with the in-progress incomplete 93v
release, which they called "93v-", but the result was dubbed "ksh 2020".
2020 had some bug fixes and improvements, but the code changes were
substantial, performance suffered, there was a lot of drama on the project.
I saw accusations that the new developer was hacking and slashing the
codebase without taking the time to understand it or listen to those who
did. I wasn't paying enough attention to know how valid the criticism was,
but the drama seems to have been enough to torpedo the project. However, if
you run "brew install ksh93" on macOS, 2020.0 is what you get to this day.

Then some of the 2020 contributors decided to start over from the AT&T
source code, backporting the bug fixes from ksh2020 onto the
last-known-stable 93u, and building up from there. Their approach is to
tread carefully and not do anything drastic.  That effort has given us the
ksh93u+X/1.x.y versions, most recently ksh93u+m/1.0.8 at the end of last
year; 1.1.0 is expected soon.

The GNU folks haven't been idle, though. The latest official bash release
is 5.2, from 2022, but the patchlevel is up to 5.2.26, and there have been
commits as recently as this week on the devel branch.

There are still at least bugfixes going into ash and dash (and busybox,
whose sh is based on ash), too. So yeah, Zsh is far from the only
Bourne-family shell still seeing active development.

--
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 3067 bytes --]

Re: Why would I use .namespace.myvar?

[Ray Andrews]

On 2024-03-10 16:53, Mark J. Reed wrote:
>
> There are still at least bugfixes going into ash and dash (and 
> busybox, whose sh is based on ash), too. So yeah, Zsh is far from the 
> only Bourne-family shell still seeing active
> development.
Thanks Mark.  Rather dramatic there with ksh.  Goes to show you the 
reason that caution should prevail.

Re: Why would I use .namespace.myvar?

[Bart Schaefer]

On Sun, Mar 10, 2024 at 7:22 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Rather dramatic there with ksh.  Goes to show you the
> reason that caution should prevail.

A similar thing happened with zsh back in the early 90s when Paul F.
and I both got real jobs (Paul never came back to zsh) and some others
took over for a while.  There's a reason you don't really find zsh 2.5
mentioned anywhere.  Of those others ... let's just say they'd rather
have been working on ksh if it had been open sourced then.

Re: Why would I use .namespace.myvar?

[Ray Andrews]

On 2024-03-10 19:35, Bart Schaefer wrote:
> On Sun, Mar 10, 2024 at 7:22 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Rather dramatic there with ksh.  Goes to show you the
>> reason that caution should prevail.
> A similar thing happened with zsh back in the early 90s when Paul F.
> and I both got real jobs (Paul never came back to zsh)
I sure do wish he'd show up and say hi.  It mystifies me that he's so 
uncaring of his masterpiece.
> and some others
> took over for a while.  There's a reason you don't really find zsh 2.5
> mentioned anywhere.  Of those others ... let's just say they'd rather
> have been working on ksh if it had been open sourced then.
I do dream of a Grand Unified Shell, where all the talent is focused on 
a single target.  But that's not the way things work.  It's a bazaar, 
not a cathedral.  Still the competition is healthy.

>

Re: Why would I use .namespace.myvar?

[Stephane Chazelas]

2024-03-10 19:53:05 -0400, Mark J. Reed:
> On Sun, Mar 10, 2024, at 6:16 PM, Ray Andrews wrote:
> 
> >  BTW interesting to learn that ksh is still in active development, I
> > thought it was on
> >  ice, like bash.
> 
> 
> Around twenty years ago, AT&T moved ownership of ksh to their open source
> arm, the AT&T Software Technology group (AST), which maintained it as an
> open project on GitHub.

Quite a few approximations in there (some and omissions at
https://en.wikipedia.org/wiki/KornShell as well actually).

Github didn't exist 20 years ago.

ksh93's code was released as OpenSource around 2000. The code
could be downloaded from AT&T research
(http://www.research.att.com/sw/download/). See
https://web.archive.org/web/20001205164600/http://kornshell.com/

AFAICT, the move to github (and to using git for revision
control)  didn't happen until 2016.

> As with prior releases, the year of the major
> release (and corresponding edition of the book) was kept as the "major
> revision" number

Though contrary to ksh85, ksh86, ksh88 before it, ksh93 was a
rewrite from scratch and significantly incompatible.

> while subsequent releases incremented an alphabetic
> suffix. The last AST release was 93u, released in December 2012 - the 23rd
> release of the 1993 version of ksh.

https://github.com/att/ast/blob/2016-01-10-beta/src/cmd/ksh93/RELEASE
or
https://github.com/ksh93/ksh93-history/blob/master/src/cmd/ksh93/RELEASE

Ksh93u was released on 2011-02-08, and stable development carried
on with two(!) "releases" tagged ksh93u+, and one ksh93v- beta
release with a bunch of new, unstable and more experimental than
ever features.

As there's been some k+, n+... releases, ksh93u is rather the
29th (ksh93a being the second).

> After that the codebase was dormant
> for a while.  Then in 2019 a developer got excited about reviving the
> project and updating it.

If you're referring to Kurtis Rader, he was active starting
around early 2018.

> They started with the in-progress incomplete 93v
> release, which they called "93v-"

It was already called v-, v hadn't been released.

> but the result was dubbed "ksh 2020".
> 2020 had some bug fixes and improvements, but the code changes were
> substantial, performance suffered, there was a lot of drama on the project.
> I saw accusations that the new developer was hacking and slashing the
> codebase without taking the time to understand it or listen to those who
> did. I wasn't paying enough attention to know how valid the criticism was,
> but the drama seems to have been enough to torpedo the project. However, if
> you run "brew install ksh93" on macOS, 2020.0 is what you get to this day.
> 
> Then some of the 2020 contributors decided to start over from the AT&T
> source code, backporting the bug fixes from ksh2020 onto the
> last-known-stable 93u, and building up from there. Their approach is to
> tread carefully and not do anything drastic.  That effort has given us the
> ksh93u+X/1.x.y versions, most recently ksh93u+m/1.0.8 at the end of last
> year; 1.1.0 is expected soon.

No, AFAIK, the m is for Martijn Dekker aka McDutchie, who's at the
initiative and main contributor of that new main stable
development. He's or at least used to be a contributor to these
zsh mailing lists as well, and might be able to give more
insight if he's still around here.

> The GNU folks haven't been idle, though. The latest official bash release
> is 5.2, from 2022, but the patchlevel is up to 5.2.26, and there have been
> commits as recently as this week on the devel branch.
> 
> There are still at least bugfixes going into ash and dash (and busybox,
> whose sh is based on ash), too. So yeah, Zsh is far from the only
> Bourne-family shell still seeing active development.
[...]

Not to mention yash, mksh (MirBSD and Android shell) and the sh
of other BSDs (based on pdksh like on MirBSD or OpenBSD or ash
like on NetBSD or FreeBSD). yash despite being much younger
could almost be considered to have overtaken bash in terms of
feature level.

-- 
Stephane