A modern programming language that makes developers happier.

kotlinlang

I was reading <https://publicobject.com/2022/05/01/eventlisteners-are-good/|the article "EventListener is Like Logging, But Good">, and I was particularly interested in the section that reads:
“Create an abstract class `EventListener`. I prefer an abstract class over an interface here ’cause I want to introduce new functions in library upgrades without breaking compatibility.”
I always thought even if you’ve got an interface, you can introduce new functions with default implementations which would let consumers not need to do anything in implementation of that interface.
Am I missing something here?

There are two separate concerns at play here:
• _consumers_ of the API - here it’s best to expose an interface, cuz, well, that’s what it is - an interface to your functionality;
• _implementers_ of the API - if the implementation is private (you don’t expect others to implement), then you have full control over this.  If you expect to have more than one implementation use an Abstract base class (or perhaps do that even for a single implementation).  
Additional functions need to be exposed on the interface; if you fully control the implementation, you can provide the implementation of those methods (no need for default methods).  If others will implement the interface (on a separate lifecycle) it’s usually appropriate to provide default methods.

My confusion was basically on the point that having an abstract class allows introducing new functions without breaking compatibility, and I was curious to understand how an interface which introduces a new function *with* a default implementation does not achieve the same goal.

it achieves the same goal, for implementers of the interface.  Consumers of the interface wouldn’t yet have seen/used those functions, so no concerns there.
Likely some hold-over thinking from older languages (e.g. Java before default functions were available).

Right, so maybe this isn’t true anymore now that default implementations in interfaces are available. Maybe since that article talks about OkHttp, it’s just that they want OkHttp to work for Java versions older than when default interface functions were a thing?

could be.  exposing implementation details (abstract class instead of an interface) leads to higher coupling / fragility, for no net value (at least in Kotlin) - poor design practice.