Hi Nigel,
I can't answer for Microsoft about their roadmap for the connector framework, but in my experience they would only consider ideas that are not on their roadmap if they receive enough votes on uservoice. That said - if you consider the overall construct that runs through Power BI, PowerApps, Flow and D365, I think it is unlikely impersonation would be "built in" to the official SPO published connector anytime soon - I could be wrong, but that's my opinion.
That doesn't mean it's not possible to build your own 🙂
You could for example, build your own custom connector for the SharePoint REST API and somehow hard code some form of credential into that process, or build an Azure function webapi to do your SPO calls for you - these approaches might work, but it would require some effort and you would still be panelbeating something to behave in a way it's not really designed to behave, which tends to introduce risk.
In the meantime, you should perhaps consider "Fit for purpose" vs "Fit for use". Based on your requirements, I would suggest to you that SharePoint, while "Fit for use" in terms of storing data for your app, is not fit for your purpose in terms of the application architecture you're looking for. SharePoint is just one of many sources your app could use - including Excel - would you be happy using Excel for your app? Probably not - just because it's possible, doesn't mean it's a good match to your requirement - the same goes for SharePoint.
The security you see as a flaw I see as fit for purpose as far as SharePoint's multiple capabilities are concerned - I would go so far as to say the flaw is in your application architecture design alignment, not the SharePoint access model or PowerApps connector framework, and here's why;
SharePoint is not a relational database from a user perspective - it's a productivity tool like many of the others that PowerApps can connect to and interact with through a REST API. While you can build PowerApps that interact with SharePoint very easily, that doesn't mean it's perfect for every application use case... When you consider the complexities of DLP, access control, foreign key constraints, execution planning and more, when you move into a mode of building architected applications (as opposed to productivity citizen dev), your data source may need to move with you.
My 10c opinion - What you really should be doing to meet your requirement is use a fit for purpose data store for your source data, like SQL or the CDS, instead of Lists in SharePoint.
This is why I don't think you will have much luck (I stand to be corrected of course) convincing the PowerApps team to build in a potentially risky (and high overhead) impersonation capability for a published connector that potentially undermines the security of the endpoint, especially when the capability exists for you to build your own custom connectors. Nothing stops you from building your own connector, but then you take on the risks of your own design.
Lastly, I'd recommend again that you load an idea on the ideas forum to drive your requirement - if you get enough votes I'm certain the dev team will at least look at it, (I've had great responses to even the oddest requests - they might not always implement them, but they will look at and consider them if hey have enough votes) - but to save you frustration in the meantime I'd really urge you to take a look at the CDS or a database like Azure SQL or something similar for your app.
If you decide to build your own custom connector, it's a great learning experience, but not without it's own frustrations and complexities - I wish you the best of luck whichever route you decide 🙂
Kind regards
RT
