ok thanks, but this is not a great system, sorry 
What system would be greater or better, then? It feels pretty intuitive to me, and no one else has complained about it.
its not a complaint, just my thoughts. 
All quotas resources and features should be set by account plans and features and each virtual server should have these 2 attached to them(example names: Feature_bronze, AccountPlan_silver etc..)
Just set below here, and by the server template on creation. You could re-use the server template system like the Admin modules were.
This is an incredibly standard thing all panels do and there is a reason for this.
I understand you want to keep the option of local overrides but for hosting companies my solution is more logical.
For example my colleague who is not technical, who runs a hosting company, completely understands the account plans and feature options but would never use a page where he has to manually select all the required virtual servers to change their settings on. He would have to keep an excel spreadsheet to keep on top of things. You dont have to do that with my uggestion.
Also I feel not having this is barring you from a lot of new users.
These are just quick notes, my GitHub issue had this laid out better.
The quickest way to explain, this is how cPanel and Plesk do it and it fantastically easy to use and allows non-techs to change settings for features and account planes .
Either re-use server tempaltes or add a features thing.
tar
Additionally: I think WHMCS is geared up for features and packages to allow for different billing patterns.
@Jamie, could you explain here why we didn’t choose “System Settings ⇾ Account Plans” to manage a domain’s allowed Webmin modules and preferred “Manage Virtual Server ⇾ Edit Owner Limits” instead.
I think that’s going a bit far. We aren’t missing the functionality itself, the disagreement here is mainly about how that functionality should be organized.
For newly created domains, the allowed Webmin modules can be defined by the Server Template. For an existing virtual servers, starting with Virtualmin 8.2.0 and later, they can be changed directly through “Edit Owner Limits”.
That said, the functionality is there. That’s a design discussion, but it’s different from Virtualmin simply not supporting it.
I wouldn’t equate either of those with Virtualmin’s server templates. Virtualmin’s model is broader and, in my view, better suited to provisioning.
Server templates control how a new virtual server is created. DNS, web server settings, initial site content, mail defaults, and etc. They are intentionally creation-time templates, and now with upcoming Virtualmin 8.2.0, Webmin module access will follow the same model, removing the previous inconsistency.
So yes, the general “plans plus permissions/features” model is common across hosting panels. What I don’t agree with is that every panel implements it the same way, or that Virtualmin needs to copy the cPanel/Plesk model to provide equivalent functionality.
I’m open to discussing whether some settings belong in Account Plans instead, but I don’t think this shows that Virtualmin is missing a standard hosting-management capability. It is not. On the contrary, in many ways it is the more capable and flexible model.
Just a quick response as I am out.
Server templates are virtualmins USP, no other system has this and allows it to be ideal for auto provisioning of apps and custom setups. Definitely keep this. 
I would see having the 3 things working in tandom:
- server template
- features
- account plan
Resource limitations I think should go in account plan as this should be controlled as well.
My original thinking was that plans control resources a user can consume, like number of domains, mailboxes, databases, etc. So which modules they can access don’t really make sense to include in the plan.
a user can consume, like number of domains, mailboxes, databases,
Yes and process resources (CPU usage, RAM usage)
So which modules they can access don’t really make sense to include in the plan.
This would be done under a new features thing.