In the comment for patch 0021 you write that the function casting type circle to type polygon cannot be error safe, because it's a SQL language function. I suggest to convert this to a C function and make the required changes there.
About the main feature patch: I'm not a fan of the CREATE CAST ... WITH SAFE FUNCTION syntax. First, the CREATE CAST syntax is part of the SQL standard. It would be weird if we needed a nonstandard syntax to make two standard features work together. Second, we didn't do this when we introduced error-safe type input functions. There is a note on the CREATE TYPE man page that use of ereturn() is encouraged, and then we left it to extension authors to do the right thing. (And we should now put a similar note on the CREATE CAST man page.) And third, requiring this would require a lot of churn in all affected extensions, requiring new extension SQL files and forcing upgrades. The changes you did in patch 0023 don't do this correctly, for example.
This leaves us in a tricky situation if we can't tell ahead of time if a cast function really can handle soft errors. We could just allow any and all (CAST ... ON ERROR) calls even if the casting function can't actually return soft errors. That's unfortunate, but it might be the simplest and best way forward given that the alternative is to raise an error at planner time guaranteeing a query failure when the values presented might not have triggered the conversion errors.
Tactical suggestion: Add an SQL-callable function, say, pg_cast_conversion_succeeds(srcvalue, desttype) that checks whether the cast would succeed. This would be similar to the pg_input_is_valid() function that we added to test the type input functions. (I did not call my proposal pg_cast_is_valid() because that might indicate merely that a casting path exists.) With that, the higher-level functionality can be constructed by hand (CASE WHEN pg_cast_conversion_succeeds(...) THEN CAST(...) ELSE 'default value' END). And then we can later work on building out the higher-level functionality and make more cast functions error safe.
You're describing the the "x IS CASTABLE AS y" syntax proposed in the same standards proposal document :)
