EXECUTE STATEMENT implementation simply calls the DSQL layer to do its job, but DSQL considers the input SQL text having the connection charset. In EXECUTE STATEMENT, however, the SQL text has the actual charset defined by the appropriate variable descriptor. If it differs from the connection charset and the SQL text contains non-ASCII characters, we get "malformed string" or "cannot transliterate" errors.
The issue can be seen if some procedure using EXECUTE STATEMENT is created in one charset, but called with another charset. Or if the dynamic SQL text is retrieved from a column which charset differs from the connection one.
I doubt it can be fixed for earlier versions (because of the layering issues), but it seems doable for v2.5 and v3.0.