in reply to
Re^7: Moose role with requirement consuming another role
in thread Moose role with requirement consuming another role
You're right, I was confusing "abstract base class" with "interface role".
That documentation mainly talks about interface roles, but in the sentence "Because the role defines the required methods directly, adding a base class to the mix would not achieve anything" presumably refers to the fact that class<-(role or abstract class)<-interface-role won't work if you only meet your interface-role requirements in the child class. "base class" in that sentence should probably be "abstract class or role". The document is really warning that you should instead use class<-interface-role plus class<-(role or abstract class).
Now if I've understood that correctly, it's still a not explaining the behavior which I'm seeing. If both has and with are evaluated at runtime and not compile-time, putting them in the correct order should mean that a role can fulfill requirements set by another role, with either a subroutine or a Moose attribute, and not only with a subroutine. I don't care that we veered off-topic, because this taught me something, so thanks!