Graphical resources are not owned by contexts or windows. You can create a sprite and display it in any existing window. Otherwise it would mean loading every resource once for every window, which is quite stupid actually 
Same remark for re-creating a window: it can happen when you just want to change the video mode; requiring to reload every existing resource in this case wouldn't make sense. I mean, for someone who's not aware of the technical details behind, why would it make sense?
The strong coupling between windows / contexts and resources is a limitation of every 3D API, and then of almost any derived graphics library. And the point is that it doesn't make any sense for almost every user which is not aware of all the technical details involved by the underlying 3D API. I don't want to just make another graphics library which is just a big wrapper around a 3D API and which inherits its limitations, actually I shouldn't even take in account the 3D API when designing my library, it's just an implementation detail.
Ok, when we're saying "graphical resource" are we talking about something like simple image data, or something like a texture? Obviously the first has no logical relation to a rendering context, but the second sure as hell does. Yes, creating render contexts from a window would mean loading duplicate resources if two windows wanted to display the same texture, and I don't see a problem with that at all. Why should two windows have the nasty hidden implicit coupling of sharing a context? It's the same reason globals are bad.
As far as the context recreation not being obvious to someone when changing video modes, you're right. Under your current design, they wouldn't expect that to happen. If it was designed the way I've suggested, they WOULD expect it because the interface makes it obvious. They still don't have to be aware of what's going on under the hood at all.
You should absolutely prevent technical limitations of an underlying API from being passed on to the user (or decide not to use that API in the analysis stage...which is why I'm not using sfml yet
). BUT, there is a reason that every API has that dependency between windows and contexts. It's not any kind of technical limitation, it's just a logical dependency that's enforced by the API's public interface.
Right on, Laurent! 
Seriously, don't ever sacrifice your ideals.
As for the "memory leak", fix it or don't. It doesn't really matter to any reasonable person, as long as you're aware of it and it doesn't grow. Wikipedia calls a memory leak "where the program fails to release memory when no longer needed." Since you're using this memory the entire time it's allocated, is it really even a "memory leak" at all? If you stopped using the memory at some point and didn't free it, then I'd agree that it's totally unacceptable, but that's not the case.
On the GetMessage()/WaitMessage()/Whatever() topic: If this was added I would use it when my game is paused/minimized. If you added it, I bet a lot of others would use it for the same reason. Other than that, I don't personally have any immediate use for it.
In any case, SFML is already an awesome library. Just avoid taking steps backwards (like forcing the user to reload resources when changing video mode) and it'll be an awesome library for some time to come.
Just my 2 cents.
Thanks!
Correct, don't sacrafice your ideals if you can still convince yourself they're valid in the face of scrutiny. Failing to do the latter is called being stubborn
I would say that memory leaks only make sense to unreasonable people. Wikipedia's definition is pretty much ok, but your assessment of sfml's handling of the leak is wrong. He does stop using the memory at some point without freeing it (the end of the program).
If your program is completely sandboxed, then yes. In that case logic says that you can free anything you allocate, no matter how convoluted your design becomes.
However, SFML isn't working in a sandboxed atmosphere. It's calling third party libraries. A third party library could be designed so that you could not free everything you allocate. I'm not saying that's the case here (in fact I very much doubt it is), but that is a possibility (I believe logic should lead you to agree).
Thanks!
Haha, you've just described why I decided not to use sfml. It is a third party library that would force my program to have memory leaks. The choice is still yours whether or not to use such a library, so control over your program's memory usage is still ultimately yours.
