I had once started writing up a feature request for improvement to the $asctime format codes, but I don't think I actually posted it because I ran into problems of figuring out how to design $asctime in a way that preserves backwards compatibility between newer and older behavior.
//echo -a $asctime($calc(978307200+3600+61+$daylight +$timezone),$regsubex(foo,$str(x,94),/x/g,$chr($calc(32+ \n ))))
This shows that the current behavior of $asctime formatting is to substitute codes in place of recognized letters, but to leave unrecognized letters alone. The exception is that the % character is deleted from the output. This means that adding new symbols like w or W could cause differences in behavior between scripts running under newer versions recognizing more codes compared to older versions which don't.
$asctime(123, wtf)
Under versions where 'w' has no interpreted meaning, it shows the literal 'w'. Under newer versions recognizing 'w' as an ISO week, it would be impossible to show a literal 'w', just like it's impossible to allow a "T" in the formatting to being shown as a literal "T" instead of being interpreted as A or P.
A happy medium would be to allow the double quote character to enclose text that's immune to being translated. so
//echo -a $asctime($ctime, HH:nn:ss $+(",$me local time") on mm/dd/yy )
would show everything inside the doublequotes without being interpreted and without showing the doublequotes themselves.
I don't know what an intentional purpose could be for having $asctime formatting swallow the percent character, so I'm guessing it's probably a bug in a routine that's not expecting an embedded % character to survive after interpreting variable names into their contents.
//echo -a $asctime(123,a%b%c%)
..simply swallows the percents and displays the abc alone.
If a 'week' symbol is added I wonder if that would have people wanting to use it for logging filenames. That would let them have 'weekly' logs which always start on the same day of the week, instead of having one of their logs ranging from day 21-28 in some months or being day 21-31 in other months.
I wonder if users would have less use for ISO week/days, or more use for week-numbers which always begin on a Sunday instead of on a Monday, or for day-of-the-year where day 1 is always Jan 1st, and Dec 31 is always day 365 or 366 depending on whether it was a leap year. Having ISO functions for the week would probably also need ISO year codes which indicate which ISO year a particular Dec 31 falls in.