We do this debate every year, and we get it wrong every year.
An ACL is a list of the form { (some-id, {permission...}) ... }
The weakness in classical ACL systems stems not from the ACL, but from the use of user identities as the ID. Bill and Mark are correct that the user identity is not aligned very well with the intentions of the program. It follows that **principal based ACLs** are a weak mechanism for certain purposes.
It does not follow that ACLs are a bad mechanism. There are other possible choices of identifiers, such as compartment identifiers, that the operating system is in a position to control and correctly maintain. Provided that the identifier is soundly chosen and properly maintained, there is nothing inherently wrong with ACLs.
I would not wish to give up capabilities. They provide a specificity of authorization that is very important. They provide fine-grain authorization, which is also very important. That said, I'm not convinced that even user-based ACLs are entirely bad as a hybrid mechanism.
The problem at the bottom is that building effective semi-permiable filters is very very very hard to get right, and is prone to creeping error as the underlying protocols change. Sometimes filters that are coarse but draconian are useful too.
Would I build them in to the operating system? Probably not at this point, though lately I've been pondering Plan-9 with some questions I'll pose in a later email.
Jonathan