Go's crypto interfaces, in the standard library, don't hew to this "accept interfaces return structs" rule. NewAES, for instance, returns a cipher.Block.
> Of course there are subtleties that I am eliding. For example, context-sensitive code would benefit very much from taking interfaces and returning interfaces
Or to steal from Haskell's lexicon: when you do something in a monad.
Serious answer: Not really. Monads are more abstract than just contexts. Monads are commonly used to represent context and contextual computation, but they can represent other things too.
What's the similarity between List, State, and IO? I'd argue that there is little similarity apart from the fact that we can define the monadic operations for all three. And, having defined those operations, we can then use more complex operations like `sequence`.
Monadic types sometimes represent data structures, sometimes represent contexts or, in the case of IO, sometimes represent nothing really at all. IO is arguably just a marker that imposes a linear sequence on what would otherwise be unsequenced computation.
In short: don't spend too much time trying to understand monads as a whole. Rather, try to understand why specific types, like List and State, happen to be monadic.
People seem to really click with the net/http design, and that does seem well done, but I imagine the standard library itself is a bit unevenly architected.
And while NewAES might predate this advice, NewGCM (which returns an opaque crypto.AEAD) does not.