I am wary of the methodology that the local proc may return expressions with an unknown number or escaped locals -- possibly without pattern in their naming, but it's difficult to judge without knowing full details. On the surface it sounds like a programming mistake. I would prefer to utilize `tools/genglobal` to produce a new unassigned global name safely than to escape a local (which is poor practice).
In examples such as for your new edit, with alpha as the dummy variable of integration, assumptions during subsequent computation would more usually be placed on x the name appearing in the limit of integration.
Your question is not about simplify (or even assuming) per se. It is about programmatic access to (and use of) the names appearing in the expression returned from the procedure. It is about handling escaped locals programmatically -- or, IMO, whether it would better practice to use a better approach that does not return escaped locals.
You can easily programmatically generate conditions from the dependent (or independent) variable names, and use those in a call to simplify (or other command) under `assuming`. That's generally quite straightforward, once you have lists of such names with which to further program.
I will repeat that I think it is poor practice to return escaped locals from a procedure. The fact that they are subsequently awkward to deal with programmatically is just one reason that it's poor. Instead, I suggest passing in a global name of your own choice or generating new (safely non-assigned) global names using `tools/genglobal` and a base name of your own choice. I realize that `tools/genglobal` is undocumented, but its usage it simple. It exists because it is used by Library routines quite a bit. It serves a rather frequently occurring programmatic purpose. I used it as a key part of an Answer to your Question of 07/07/2020 and another Question of 19/09/2020, both of which have similarities in vein to this thread.