12.2 "Parsing HTML documents" says:

    The error handling for parse errors is well-defined: user agents must
    either act as described below when encountering such problems, or must
    abort processing at the first error that they encounter for which they
    do not wish to apply the rules described in this specification.

But it's not clear what "act as described below" refers to. The subsequent paragraphs in the section apply only to conformance checkers.

Similarly, it's not clear what "the rules described in this specification
[for parse errors]" are.

My guess is that they're referring to phrasing such as:
    Parse error. Emit the current input character as a character token.
(in 12.2.4.1 Data state). That is, if the user agent arrives at this point,
it can either "abort processing" (though it's not entirely clear what that
entails), or it can "act as described" (i.e. emit the current input character
as a character token), and proceed as if nothing untoward had happened.

(And while a conformance checker can do either, it also has a duty to report
the error, modulo the existence of other errors. Other user agents don't appear
to have even the /option/ to report errors, though presumably they do have that
option, e.g. via an Error Console.)

However, there are also places where the spec simply identifies a parse error,
without any accompanying [recovery] behaviour. E.g.:
    12.2.2.4 Preprocessing the input stream
        Any occurrences of any characters in the ranges ... are parse errors.
    12.2.4 Tokenization
        When an end tag token is emitted with attributes, that is a parse error.
If a user agent encounters these situations, and doesn't want to "abort
processing", what can/must it do?

In summary, this is a request to make all these points clearer.