Interface Default Methods

Prevents having to add a trait to every class that has to implement an interface, being able to provide default implementations via interfaces would be a large DX improvment

Most of the time when creating an Interface that shares some implementation we would always create Interface + Trait. This is just more work. With Interface default methods we would get rid of the Trait and be able to have it in the interface already!

it's works great in other languages like java and kotlin.

It's possible to improve backwards compatibility without default method implementations in interfaces.

Similar concept exists in Kotlin, Swift (extend protocols), Java, C#, and other languages, and it has proven to be quite useful in those ecosystems.

I understand the downside of not having multi-inheritance available in PHP. However, IMHO this should not be solved by allowing implementation specific code in interfaces. That's not what interfaces are meant for.

Interfaces are contracts. No implementations should be allowed.

I don't think we need to add business logic to interfaces. Interfaces are contracts, that's the whole beauty of interfaces (that, and the fact that they encourage composition over inheritance, which imo leads to code that is easier to maintain). Having default methods would pollute that premise.

We can already do this with abstract classes. I believe Interfaces should be contracts that leave the implementations up to the implementing classes.

Interface should not contain implementations

An interface is a contract, that should define what the behaviour of an object is. If you need default methods, use an abstract class that implements said interface. If you require more than one abstract class, you can use traits, or your class structure is probably wrong

If I have an interface with getItem(), hasItem() and a findItem() methods , it would like to provide a default implementation for hasItem() and getItem() that use findItem().

This way I don't need to create a trait for this .

Interfaces should define contracts and stop there. Concrete behavior, even as simple as the log example by Brent, should be implemented on an abstract class or on specific classes.

An interface should only describe a contract that a class must adhere to and nothing else. If there is a commonly repeated segment of code to implement part of an interface, I believe that this can be covered with a trait, as it is clearly opinionated in how this interface should be implemented.

My vote is towards being able to add interfaces to traits.

Interfaces should only give the form of the class that implements it, not its implementation. This is the role of abstract classes.