Multibyte output confuses "print -c" ?

[Bart Schaefer <schaefer@brasslantern.com>]

I'm not entirely sure what's going on here, but:

zsh% autoload define-composed-chars
zsh% define-composed-chars
zsh% print -C 10 -- \<'\U'${(l.8..0.)^${(s. .)zsh_accented_chars}}\>

Note that the columns are not all the same width and in many cases the
closing angle bracket does not appear.  I also get exactly one "zsh:
character not in range" error, see more on that below.

Comparing the output of "print -C 1" and "print -l" on that same expansion,
there appears first to be a problem with columnation of strings containing
a nul byte.

zsh% print -c '<\U0000000T>'
<
zsh% print '<\U0000000T>' | cat -v
<^@T>

Digging a bit deeper, I find there are also some embedded newlines in the
values of $zsh_accented_chars that I don't think should be there:

<000448\nd>
<00042B\na>
<000044B\n>

So that indicates a problem in define-composed-chars.  However, there still
remain a number of cases where print fails with either -c or -l.  Digging
still further, I find that if I individually print each of the failing
values, every one of them produces "zsh: character not in range" -- but
if I print them, say, in a "for x in ..." loop, the only every alternate
one of them gives the error, and if I print multiple of them in the same
single print statement I get the error only once.  The latter sort of makes
sense but the loop behavior must be wrong; something is not being reset in
the interpolation for '\U...'?

--