When I create an Add-in, I can request Read permission for a single SharePoint List in the AppManifest.xml file. Later, when the user installs my Add-in, SharePoint asks her/him for the name of exactly one list to grant my Add-in read access.

I want my Add-in to have the ability to read from multiple lists from unrelated site collections, but I don't want to request read access for the entire tenant.

Please modify SharePoint Add-in security so the user has the option grant an Add-in access to multiple lists for which she/he has access across the tenant.

For example:
If a user installs an Add-in into a site named Food Manufacturing with lists named Equipment, Meetings and Processes, I would want the said user to be able to not only grant my Add-in read permission to the Equipment and Processes Lists but also grant my Add-in read permission to the Vehicles and Personnel lists of an unrelated site named Corporate Assets.

I need this behavior because a portion of my user base wants to collect information across several disparate locations of the same SharePoint tenant and summarize it all in a single place. I can probably do this by requesting tenant level read access for my Add-in, but that seems excessive and I don't think my users will be able to install the Add-in at that point since they shouldn't have that level of scope.

As mentioned here

https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/add-in-permissions-in-sharepoint

and here

https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/app-only-elevated-privileges-sharepoint-add-in

it ist stated, that using AppOnly Permissions is restricted for UserProfile and TaxonomyStore (whereas Taxonomystore is unclear).

However, as now CSOM supports .Net core, but only with AddIn-Model authentication, we have no possibility to use that to update UserProfiles or TaxonomyStore in an automated way in the backend using .Net Core.

At least if that documention is still correct.

Currently we have to use a service user and .Net Framework CSOM to do that tasks. But this on the other way prevents us to use new technologies for example in Azure, which is moving to .Net Core (eg. Functions support .Net Framework only in oldest v1-Version).