Perhaps rather than changing ABCMeta, provide a base descriptor class that has __isabstractmethod__ implemented to calculate the abstractness.  Then property could use that, as could any of the other relevant descriptors we have around.  The __isabstractmethod__ attribute of the descriptor would itself need to be a data-descriptor (which property() is).  That would ensure that __isabstractmethod__ is not set directly on the descriptor instance.

I agree with Nick that it may be better to have the descriptor classes take care of managing __isabstractmethod__ themselves, instead of having ABCMeta compute it.  Special-casing ABCMeta to handle custom __isabstractmethod__ calculation for any specific type seems like something we should avoid.

Per your last message, if a specific descriptor has an abstract setter then the descriptor should be considered abstract.  If the implementation of that attribute is not a descriptor should it raise a TypeError?  If it is a descriptor but it does not have a setter, should it likewise fail?  I'm not so sure.  We already don't enforce types on abstract attributes.  You don't have to implement an abstractproperty with a property, an abstractstaticmethod with a staticmethod, nor an abstractclassmethod with a classmethod.  For that matter you don't have to implement an abstractmethod with a function.  It just has to be an object bound to the same name.  Should descriptors get special treatment over any other type that implements __isabstractmethod__?

That brings up a concern of mine.  I've found the name abstractmethod (specifically the "method" part) to be misleading.  Any attribute can be "abstract" and ABCMeta only cares about __isabstractmethod__.  Maybe having "method" in the name is meant to imply the expected use case?  I would rather they were called  __isabstractattribute__, and __abstractattributes__, which would be less confusing when using ABCs, particularly at first.  Having "attribute" in the name is nice, since it makes it clear we're talking about attributes, rather than other abstraction contexts.  Having a specific abstractmethod decorator is still good since we only decorate functions in an ABC.

I'm +1 for deprecating abstractproperty and really all the decorators except abstractmethod (if the use cases were addressed).  If abstractmethod were smart about on which object it sets __isabstractmethod__, the other decorators would be unnecessary;  and the order in which you decorate would not matter as much.  The other decorators could become simple wrappers around abstractmethod if we felt the need to keep them around.  It's nice that the decorators say with what you are expecting to replace them, but you can get that by using the corresponding normal decorators.