Just look at the Visitor pattern. It's a convention to expose an "accept" method that can be "visited". That's pretty much what you'd do far easier and more naturally with functional programming these days, even in Java. Going in depth, you can see the same possibilities everywhere. "Proxy" should probably be a registerable middleware, etc. etc.
Then again, I might be biased. Design Patterns already let my BS detector go bonkers 15 years ago when I encountered them first, as as academization and complication of software by self-indulgent "enterprise programmers" that I couldn't ever see any advantages to (and these days, I feel enjoyably vindicated).
Funnily enough, in this way they were quite anti-academic, as they came from original research of the "Gang of Four" and I've never seen scientific proof they actually made anything better. I stand to be corrected though.
but it's still a pattern ? patterns aren't classes. A specific way of sequencing function calls and operators is still a pattern.
Are "just" an interface a data type can implement/obey (in languages that support higher kinded interfaces)
> a foreach method/function for iteration over data
Again, "just" an interface a data type can implement/obey.
Yes, exactly what I meant by
> the design patterns relevant in those domains are not really called "design patterns".
I was thinking of things like algebraic or categorical laws, or invariants.