Being curious about internals and giving users the means to understand them doesn't conflict with the goal of a) putting them behind a hiding layer that reduces the aspects a user needs to keep track of and b) avoiding dependence on those internals staying the same.
You can still teach people how things work or you can still have a list of potential implementations of an interface.
Where the internals matter you would either define very strict contracts or not use abstraction mechanisms that hide internals. But where it matters is not everywhere.
In the past (http://akkartik.name/post/libraries) I've tried to distinguish between giving things a name to avoid having to work through details over and over again, and relying on something built by others so one never has to think about the details. But this has been a difficult point to communicate. I usually try to avoid the term 'abstraction' because it's gotten so debased. But here for an academic audience I go with the grain of how people use the word.
You can still teach people how things work or you can still have a list of potential implementations of an interface.
Where the internals matter you would either define very strict contracts or not use abstraction mechanisms that hide internals. But where it matters is not everywhere.