For quite a few versions now, it's been possible to edit the schema source and put occurrence constraints on a field. Nobody uses this, because it has no effect on the way a component is displayed, and if a user violates such a constraint, the error is just nasty: certainly not a user-oriented way of saying what's wrong.
It's common enough for a site design to dictate that, say, in a given place you can put up to three widgets, or whatever. It's a real shame that you can't really do much about this until render time. The same goes for other constraints like the length of a string, or a pattern restriction. All these things would be great to have, but there's no point unless the UI also understands these constraints and displays things appropriately.
Ideally, then we'd never need to show an end user a message about violating a schema restriction, as the UI would have made it impossible, but if it were necessary, we could also do with some user-friendly reporting about why exactly you can't save the component.
Some of the occurrence constraints are already enforced like min/max for multi-value fields and the rest inside Experience Manager.
The other two parts for us to consider here are:
- Schema options to set the available constraints
- Near real-time validation of the constraints for users for each type and across the UIs
Regarding the example of constraining number of Widgets in a given place on a Page: that is covered by Region constraints in Tridion Sites 9.