Many things in the proposal are deliberately restrictive, such as Corinna only allowing single inheritance. This is to allow Corinna to be cautious in not promising too much. If we later find this too restrictive, we can allow multiple inheritance. However, if we start with multiple inheritance and discover we don't need or want multiple inheritance, we would break existing code by taking it away. Any proposals to change the RFC must consider the principle of parsimony.
In practical perl, multiple inheritance is used, composition is used, delegation is used, roles are used. None of these concepts or their usages are going away.
Making use of two backronyms, I'd say that you are too much inclined towards the "Pathologically Eclectic Rubbish Lister" notion and not so towards the "Practical Extraction and Report Language".
To put it bluntly: I'm just your average programming Joe, with no degree in Math or CS whatsoever. If I was to adopt a better perl OO in-core approach, I'd like very much to take it piecemeal, adopting each part as I am fit to do so. I want guidance, not restrictions. Your approach is far too much academic to my taste and needs, and it imposes a learning curve too steep for me to climb, at that age. After all, python might be a better choice, boring as it might be.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'