Looking at the aaPanel's Python Manager today, I've been surprised by two points that, maybe, could be added in your roadmap:
It requires that the mapped domain's tree on disk doesn't exist previously. Knowing (from what I saw), you create a separate proxy conf file for Nginx that you include in one line in the main conf file for the concerned domain, I think it couldn't hurt to add this same line in an existing conf.
It considers that the Python app is obligatory at domain root (ie. /). On my part, I've several (hosted) websites embedding Python app (and sometimes several in the same site) with an access which doesn't start at the entrance of the site (eg. a website where index.html is a plain static page delivered by the web server and some javascript code calling different routes to a Flask app behind the scene). This kind of design where an entire domain is not absolutely an app only has been taken in charge by Phusion Passenger for example; in passenger, when you create an app, you decide about the URI leading to it. In Apache, I guess it's managed by htaccess, but in Nginx, it's just something like below where my Flask app is reachable at http://domain.tld/hello/ instead of http://domain.tld/.
location /hello/
{
proxy_pass http://127.0.0.1:5000/$1;
...
Also, and I'll stop here: I saw it's not possible to change the initial settings afterwards. For example, if you want to switch from gunicorn to werkzeug or change the path, you have to recreate the Python Manager config.
My two cents 😉 However, nice to have this interface...
