Array parsing incorrectly accepts ragged multidimensional arrays

While working on Postgres-compatible array support in Materialize, my
colleague Sean Loiselle (CC'd) discovered what a class of seemingly
invalid array values that are accepted by Postgres's array input
routine:

benesch=# select '{{{9}},{8},{7}}'::int[];
 int4
------
 {}
(1 row)

benesch=# select '{{9},{{8}},{7}}'::int[];
 int4
------
 {}
(1 row)

benesch=# select '{{9},{8},{{7}}}'::int[];
          int4
------------------------
 {{{9}},{{NULL}},{{7}}}
(1 row)

As far as we can tell, Postgres *should* reject all these array
values, as the elements of each dimension do not have uniform length.

Postgres does correctly reject the analogous test cases with one less
layer of nesting:

benesch=# select '{{1}, 2, 3}'::int[];
ERROR:  malformed array literal: "{{1}, 2, 3}"
LINE 1: select '{{1}, 2, 3}'::int[];
               ^
DETAIL:  Unexpected array element.
benesch=# select '{1, {2}, 3}'::int[];
ERROR:  malformed array literal: "{1, {2}, 3}"
LINE 1: select '{1, {2}, 3}'::int[];
               ^
DETAIL:  Unexpected "{" character.
benesch=# select '{1, 2, {3}}'::int[];
ERROR:  malformed array literal: "{1, 2, {3}}"
LINE 1: select '{1, 2, {3}}'::int[];
               ^
DETAIL:  Unexpected "{" character.

I whipped up a patch that causes Postgres to correctly reject the
three examples above [0], but I am not convinced of its correctness.

Do folks agree that this is a bug? Is it worth me or Sean formally
submitting the proposed patch, or would someone with more experience
like to do a more thorough refactor of the ArrayCount routine?

[0]: https://gist.github.com/benesch/2e77712f81625deeb0e2246098fd8089