lawman Most adversaries are low competent, so could you please allow useful features which only work against low competent adversaries.
Eg. Hidden user profiles (only visible if entering the correct pin)
I understand GOS developers don't add this killer feature because NSA level adversaries could see hidden profiles.
That reason for refusing to consider is unhelpful as most adversaries are low competent and world be catered for.
I don't speak for the GrapheneOS developers, but I believe they already feel they have enough high-priority items in the queue to discourage in-depth consideration of low-strength/low-deniability countermeasures. As just one example, my sense is that there are ongoing issues related to structural issues in AOSP's VPN infrastructure. I can imagine that avoiding VPN leaks might seem more important than hidden user profiles.
Something else to keep in mind is that every feature added by GrapheneOS must be maintained while the underlying AOSP changes monthly. That means that features that are "done" must be re-implemented from time to time. Google has been making changes to the user-profile infrastructure (e.g., Private Space, which may not be completely done yet), and my understanding is that there have been hints of making other changes (e.g., booting into secondary user profiles without needing to unlock the owner profile). Given that, I can understand why the GrapheneOS developers may be reluctant to add major user-profile features.
It is clear that some people want hidden user profiles, but it is also clear that this would be difficult to do solidly, and meanwhile even doing it less-than-solidly would probably require expensive reimplementation work.
One way to resolve this difference of opinion would be for somebody to design and build the feature in a GrapheneOS fork, and submit the implementation for consideration after it's completely built. The GrapheneOS project might not decide to incorporate it even then, in which case perhaps the fork would become permanent. I suspect that approach would be more productive than requesting something that the GrapheneOS developers have already heard requests for, and have said that they don't plan to implement.
By the way, I don't think it's accurate to say "refusing to consider" when the matter has been raised before and responded to before. Considering does not always result in agreement or compliance.