Nanoflow calling a Microflow should get access to its error

I'd like to propose a potential improvement to the way errors are handled when propagating from microflows to nanoflows. Currently, while error events trigger correctly, accessing the specific error information within the calling nanoflow can be challenging. This limits the granularity with which we can handle errors at the nanoflow level.

My suggestion is to allow error end events in microflows to return a string value, similar to a standard end event. This string could then be populated into the $latestError variable within the calling nanoflow.

Benefits:

• More informative error handling: This would allow developers to craft specific, context-rich error messages within the microflow's error handling branch.
• Improved error propagation: The $latestError variable in the nanoflow would then contain this detailed message, providing more actionable information for the nanoflow's error handling logic.
• Greater flexibility: This change would significantly increase the flexibility and power of error handling across the client-server boundary.

Essentially, this would provide a mechanism to surface useful, developer-defined error context from microflows to nanoflows, leading to more robust and maintainable applications.