First of all, thanks for bringing this up. I'm glad to enhance it with real-world use cases.

Generally, the FederatedResourceQuota is designed to enforce quota restrictions on Karmada control plane. But, currently, it just provides a capacity for administrators to manage the ResourceQuota across clusters, by the StaticAssignments. I guess, as lack of feedbacks, it saves the efforts to propagate Kubernetes ResourceQuota by a PropagationPolicy.
The general ideas and possible approaches are listed in the comments..

I guess your idea is to let the user declare a total quota by FedratedResourceQuota for a specific namespace, and the quota can be shared across clusters.
In your first diagram, the total quota is 40 CPU, member1 and member2 used 20 each. At this point, no more applications(require CPU) can be scheduled to both clusters in that namespace as the total quota out. Since Karmada handles the process of failover, it knows after the failover, the quota will be released from member1, so it still can schedule application to member2 temporarily. Please correct me if I'm wrong.

Thanks for taking a look!

In your first diagram, the total quota is 40 CPU, member1 and member2 used 20 each. At this point, no more applications(require CPU) can be scheduled to both clusters in that namespace as the total quota out. Since Karmada handles the process of failover, it knows after the failover, the quota will be released from member1, so it still can schedule application to member2 temporarily. Please correct me if I'm wrong.

Pretty much yes. In our use-case, we have a controller that syncs a tenant's resourcequota on each member cluster to be equal to the tenant's limits (lets say 40CPU and 50GB). Each cluster will an identical static resourcequota (so that 1 cluster can accommodate all of the tenant's workloads if necessary in the case of DR).

But we want the FederatedResourceQuota to monitor the existing quota usage across all clusters and set a limit on the amount of resources that can be applied to the Karmada control plane. In the comments you linked these two were most relevant:

	//   - The rule about how to prevent workload from scheduling to cluster without quota.
	//   - The rule about how to prevent workload from creating to Karmada control plane.

Perhaps this would require some sort of admission webhook that would prevent resources from being applied if their total resource usage would go above the limits defined in the FederatedResourceQuota. This would mirror the way that ResourceQuotas are defined in K8s. The more difficult part would be determining when to replenish the quota (perhaps when a work is deleted?).

Perhaps this would require some sort of admission webhook that would prevent resources from being applied if their total resource usage would go above the limits defined in the FederatedResourceQuota.

Yes, exactly. In addition, the scheduler also should take the resource quota into account and prevent scheduling workloads from clusters that exceed the limitation.

By the way, I might be slow to respond on this topic and I wish to pay more attention to #5116 and #5085 and the others we planned in the current release. But I'm interested and glad to have this discussion, and hoping keep this open and welcome other people to join this.

By the way, I might be slow to respond on this topic and I wish to pay more attention to #5116 and #5085 and the others we planned in the current release. But I'm interested and glad to have this discussion, and hoping keep this open and welcome other people to join this.

That's alright! Apologies for all the issues that have been filed recently - one at a time. :)