Log policy usage contradicts with "log backend information" feature

There has been problem discussed under IBM Case that due to usage of Global Policy we are blocked from using "backend information collection" feature to capture headers/payload backend into API analytics event.

In our setup:
1. We have global policy configured on pre-request when we are logging extra fields in custom_data part of API Event. As required global policy contains Log Policy to do so.
2. Because of Log Policy usage so early in the flow "collect-data-for-analytics: true" feature in invoke policy doesn't work and we are not able to propagate backend information to our analytics event.
3. As it has been discussed moving Log policy and custom data propagation to post-response part of global policy would be workaround here but it would also enforces us to implement very complex on-error policy and reconstruct all error messages/error codes for all possible error types. This is no-go for us as the risk of breaking existing interfaces is too high.

Possibility to log backend information (especially request headers after transformations in API assembly) is important feature to ensure smooth troubleshooting and operational stability of API Gateway.

The suggested improvement could be to automatically propagate backend information together with other standards fields automatically at the end of the flow (like response code, response headers etc) regardless of usage of Log policy in the assembly flow.

Here are extra solution requirements defined under IBM Case:

•    Preserve previously added log.custom_data.
•    Collect backend request and response information after the Invoke.
•    Avoid duplicating Log and GatewayScript logic across normal and error flows.
•    Preserve existing consumer-facing error responses without reconstruction.
•    Provide a supported solution that can be applied centrally through global policies without interfering collection of backend information.

There is similar RFE created https://ideas.ibm.com/ideas/APICONN-I-1197 to get rid off of the Log Policy usage for custom_data which might be part of the solution we are looking for but this one does not fully cover our scenario.