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