Skip to the end for the concerns and questions

Summary

Recently, I've been testing GrapheneOS device IDs and fingerprinting, particularly to determine the viability of running the same app on two separate profiles without the app provider knowing it's installed on the same phone Some examples: communication/VoIP apps where you don't want the VoIP provider to link your identity between the two numbers/accounts or Google apps where you know invasive fingerprinting may be a concern and don't want Google knowing Account A is on the same device as Account B.

The Test

For this test, I used a variety of device ID and fingerprinting apps, but it turned out that using only one was sufficient. The results you can see in the table below are from Fingerprint OSS Demo app - the same company made this that's behind the powerful https://fingerprint.com. Instead of posting the actual ID values, I replaced them with single-letter representations. All profiles are exactly identical aside from what is in the Setup column.
GS = Google Services; GP = Google Play Store app; Stable/Optimal/Unique = three different fingerprinting methods
GSF ID = Google Services Framework ID
I made two profiles each with GS and GP installed, one profile with just GS installed but not GP, and two profiles with neither GS or GP installed. I actually suspect that the fingerprinting app may be mislabeling the GSF ID and Android ID, but for this test, it's not particularly important if they named it right or not.

The Results

Results Table
The results displayed in the table show that the Stable and Optimal fingerprinting gave the same value across all profiles, but the Unique fingerprinting gave a different result based on the combination of GS and GP that was installed, but did give the same results otherwise. The so-called GSF ID and Android ID were different on all profiles, and the Android ID was not present unless GS was installed. The Media DRM ID (MediaDRM) was the exact same across all profiles and only changed if the whole device was factory reset.

This table provides information on which identifiers remain consistent across profiles and device actions (like factory reset) and is very useful for trying to understand the mitigations needed to prevent device identification (link: https://github.com/fingerprintjs/fingerprintjs-android/blob/main/docs/stability.md)

Concerns and Questions

This was a very limited test, but it still showed the limitations in preventing different apps, even those in separate profiles, from being able to uniquely identify the device they are on. This is concerning because if two different apps collude (e.g. if the owning company is the same or the companies share data) or if you have the exact same app installed on different profiles (e.g. Google Maps used for work locations on a "work" profile and Google Maps used for personal locations on a "personal" profile), this enables your identity to be easily linked even across totally separate profiles.

Below is just a sampling of the data available to an app with no extra permissions that were used to fingerprint:
Media DRM ID
Applications List
System Applications List
Screen Off Timeout
Font Scale
End Button Behavior
Time Zone
Battery Health
Battery Full Capacity
PIN/Fingerprint Status
...and more - a complete list of data points is provided in the app

Why does every single app needs to have access to the MediaDRM since it is a static, unique identifier? It's as bad as giving access to the IMEI minus the factor reset capability.
Is it possible for GrapheneOS to generate a unique MediaDRM value for each profile?
Is it possible to spoof device fingerprinting data points such as the battery capacity, PIN status, time zone, etc. unless the user agrees to allow apps to access this treasure trove?
The main question: In your opinion, what is the viability of having the same (non-privacy-respecting) app installed on two separate profiles and preventing it from determining they are both on the same device? Are there any particular steps to take to achieve this?