core: Error handling with 3.2 is inconsistent & difficult

Description
With 3.2 there are two different ways in which error responses are created:

1. When the problem occurs while routing or authentication, Symfony’s own ProblemNormalizer is used.
2. When the problem occurs within ApiPlatforms Processors/Providers an ApiResource\Error is created and serialized. (At least when using no deprecated features / the new problem responses)

This leads to multiple problems:

• returned content + headers change for similar errors / same status codes: see #5961
• We can no longer decorate ‘api_platform.hydra.normalizer.error’ to modify all returned error responses, e.g. to translate the returned error ‘detail’ / ‘hydra:description’.
  • instead we have to create a new Processor to decorate ‘api_platform.state_processor.serialize’ to modify the ApiResource\Error error before it is serialized
  • and modify our existing serializer to instead decorate ‘serializer.normalizer.problem’ to do the same thing but on an array
• ApiResource\Error is immutable, which requires us to create a new instance to modify a single value, e.g. the ‘detail’
  • Why are there no setters, and if it is required to be immutable, can we please get ->with...() clone methods like most of the ApiPlatform\OpenApi\Model classes have (withParameters, withTrace, withDescription, …)? Also the ORM|ODM|ElasticSearch\State\Options or the MetaData class(es) have them.

The feature request would be to simplify the modification of the error results, for all error sources together and to better document how this can be done. Currently the docs (https://api-platform.com/docs/core/errors/) neither shows how to use a Provider nor a Serializer to modify the response, and it does not mention the (current) differences in error handling & output.

Example
We want to translate the error messages generated by Symfony’s routing / Lexik JWT / Validators / custom exceptions to be parseable by the API-Client. Currently we have to use:

    $clone = new Error(
        $data->getTitle(),
        $this->translator->trans($data->getDetail(), [], 'validators'),
        $data->getStatus(),
        $data->originalTrace,
        $data->getInstance(),
        $data->getType(),
        $data->getHeaders(),
    );

and

        $result['detail'] = $this->translator
            ->trans($result['detail'], [], 'validators');

        // currently not available because of #5961 
        //$result['hydra:description'] = $this->translator
        //    ->trans($result['[detail](hydra:description)'], [], 'validators');

which also causes the Error constructor to iterate over the whole stacktrace again to remove the (already removed) args. (yes, we could first provide an empty array as trace and later simply set $data->originalTrace, see below)

Additional context

    defaults:
        extra_properties:
          rfc_7807_compliant_errors: true
          skip_deprecated_exception_normalizers: true
    event_listeners_backward_compatibility_layer: false
    keep_legacy_inflector: false

Additional questions / feedback

• Why is (only) the originalTrace public in ApiResource\Error? What was the reason to not use a getter like with all other properties and an additional setter?
• What is the reason behind making all properties private instead of protected? This prevents extending the Error with a custom subclass as it cannot access those props. It is neither marked final nor internal (which is a good thing imho).
  • This is a theme I see often in ApiPlatform (but also in Symfony in newer history): Classes are marked final or most/all properties and methods are private which prevents inheritance, which often causes repetition as we only want to change a small portion of the code but need to copy everything else as it cannot be re-used.