As far as that goes, it shouldn't be that hard to deal with, at least not for "soft" errors which hopefully cover most input-function failures these days. You should be invoking array_in via InputFunctionCallSafe and passing a suitably-set-up ErrorSaveContext. (Look at pg_input_error_info() for useful precedent.)
Ah, my understanding may be out of date. I was under the impression that that mechanism relied on the the cooperation of the per-element input function, so even if we got all the builtin datatypes to play nice with *Safe(), we were always going to be at risk with a user-defined input function.
There might be something to be said for handling all the error cases via an ErrorSaveContext and use of ereturn() instead of ereport(). Not sure if it's worth the trouble or not.
It would help us tailor the user experience. Right now we have several endgames. To recap:
1. NULL input => Return NULL. (because strict). 2. Actual error (permissions, cache lookup not found, etc) => Raise ERROR (thus ruining binary upgrade) 3. Call values are so bad (examples: attname not found, required stat missing) that nothing can recover => WARN, return FALSE. 4. At least one stakind-stat is wonky (impossible for datatype, missing stat pair, wrong type on input parameter), but that's the worst of it => 1 to N WARNs, write stats that do make sense, return TRUE. 5. Hunky-dory. => No warns. Write all stats. return TRUE.
Which of those seem like good ereturn candidates to you?
