A few thoughts here:

1. We probably need some core devs to chime in on whether a behavior change is justified from NumPy's perspective. I don't see many of the regulars discussing in either of the issues at this stage. We'd be breaking from presumably long-term documented behavior, even if it is a bit odd.
2. Even if folks were in favor of a change that is not backwards compatible, on the basis that it might be considered a "bug fix," we'd almost certainly need to add some tests for various scenarios.
3. What happens when the functions in funclist output values with dtypes that can't safely be combined?
   • Should we even convert out to object in weird cases?
   • Should we allow out to have its dtype size reduced relative to x if all functions in funclist return smaller width types than current type of x? I can imagine this breaking some control flows in potentially surprising ways perhaps.
   • is there anything to stop one of the functions in funclist from returning different types in different cases? You can pretty much make these functions do whatever you want with the return type, right? So, wouldn't it be hard to rigidly define what happens in these cases? Oof.

@tylerjereddy Thank you for reviewing the code. You're right the changes do alter the traditional behavior. One thing I could think of, to support backward compatibility, is to introduce a flag which could allow the user to specify if they want to match the output dtype with the function output dtype or match it with the input dtype. I believe this could potentially answer the second point that you made. And finally, I can modify the implementation to match the piecewise output dtype with highest precesion output of all the functions in the funclist, but you're right we would require additional tests to make sure that there isn't any unexpected behavior. But yeah definetly need some intput from the core developers on the issue since any changes would result in modifying traditional behavior.