I totally understand the caveats, and this discussion is just what I was hoping to get to with the ask. I think that it being the user's responsibility to configure group mappings if they want to use that feature is a very reasonable approach that strikes the right balance of maintainability and functionality. It's worth noting to people that it's an advanced thing you should only be working on if you know what you're doing and that it's not something that Cloudron can or should support beyond basic information about how the LDAP server side works.
A lot of this varies app-to-app, and frankly, I think it's appropriate to leave the nuances of the choices a user might make about how those apps behave to said user. Some apps are super powerful here, like Metabase, which can basically automate all of the role/group assignments for you if configured right, ranging all the way back to EspoCRM, which is basically non-existent in its support for group mappings besides basic login filters, which is already better handled by Cloudron anyway, and plenty of others like osTicket that are somewhere in between.
I think good points have been raised about the security concerns and sync issues, and it's worth making it clear where the line is on what's provided vs. what's possible. Furthermore, as packages update into the future and more support for group mappings is added, it would be unreasonable imo to expect Cloudron packages to anticipate everyone's preferences/needs. Patterns of use will vary hugely based on how the systems are deployed and by whom. The points above all sounds like you've gotten a pretty clear idea over the years of this one coming up about how to equalize the flexibility and clarify the boundaries for expectations with such a feature, all of which sound exceedingly reasonable, whether groups are implicitly all LDAP or explicitly configured in or not (minor detail to my mind).