the problem goes far worse.
The compiler doesn't stop on polyhedron errors. In a complex sweep operation you can easily create millions of ERROR: lines in the console without any means to stop the run.

obj=[[0,0], [0,1], [1,1], [1,0]];  
polyhedron(obj[0], [0, 1, 2, 3]); 

ERROR: Unable to convert points[0] = 0 to a vec3 of numbers in file , line 2
ERROR: Unable to convert points[1] = 0 to a vec3 of numbers in file , line 2
ERROR: Unable to convert faces[0] = 0 to a vector of numbers in file , line 2
ERROR: Unable to convert faces[1] = 1 to a vector of numbers in file , line 2
ERROR: Unable to convert faces[2] = 2 to a vector of numbers in file , line 2
ERROR: Unable to convert faces[3] = 3 to a vector of numbers in file , line 2
Compiling design (CSG Products generation)...

I agree that we need a way of stopping on errors. Currently, both the test frameworks and some people may rely on the current behavior, so I'd suggest that, as a start, we silently introduce a UI + cmd-line setting for this, potentially merged with the existing hardwarning setting.

The question is how to (short-term) structure it for backwards compatibility, until we clean up tests etc., and (longer-term) set up good defaults.

Long-term, I'm not sure if this is appropriate for OpenSCAD, but from the compiler world (e.g. clang), we have the concept of first deciding to upgrade warnings to errors (--Werror) , then how to deal with how many errors to accept before aborting (-ferror-limit=), with a bunch of ways of tuning this behavior with additional flags.

The current behavior is indeed a bit weird; default is like clang's -ferror-limit=0 (unlimited), but with --hardwarning, all warnings are upgraded to fatal errors, while the error limit is still unlimited.