FBOs aren't shareable between contexts. You need to bind it in the same context that you created it in. This would mean that you would need to activate the shared context every time you want to bind and draw to the FBO. This would work, if it weren't for the fact that SFML likes to leave contexts activated forever until another gets activated (implicitly deactivating the previous one). And keeping the shared context activated might look like it works on paper, but at least on Windows, if the shared context is currently active on any thread, any newly created contexts that want to share resources with it (and therefore all other contexts as well) will not be able to, since wglShareLists() will fail half the time for whatever mysterious reason.
And then there's the issue of using the contexts as a container for the current render state. I don't know if this was part of the original design Laurent came up with, but keeping every target in their own context "simplifies" state management. RenderTarget does a crap load of caching in order to reduce "unnecessary" state changes. This only works if it is guaranteed that nothing else can touch the state. It's already bad enough that people who want to use GL have to resort to pushGLStates(), popGLStates() and resetGLStates(). If we threw all FBOs and thus RenderTargets into a single context, we would have to do the same among them as well.
The reason why I said unnecessary in quotes is because this is what it might look like at first glance. Indeed many newcomers to GL learn to cut down on redundant state changes. However, that advice also comes with a caveat: The assumption is that those users are working in a single context environment.
We might think that we are being smart and saving state changes, but anybody who has an idea of how drivers and GPUs work internally know that whenever you switch contexts, you are just causing a bunch of state changes that we don't notice in our code. We are moving them from application CPU time into driver CPU time, which ends up providing us with no benefits whatsoever. This is noticeable because in addition to OpenGL incurring a fair amount of overhead, SFML causes the driver to eat up a bit more CPU time when compared to other single context applications.
Multi-context is just a convenience. It doesn't map directly to the hardware and therefore comes with overhead. It was designed before DMA became a thing and thus doesn't take it into account. The only time when multi-context benefits you is when you know exactly what the driver has to do and can force it to do it in a secondary thread, this includes DMA. No matter how hard you try, all these classic APIs like OpenGL and DX up to 11 are inherently single threaded. It's a good thing that people woke up and changed that in Mantle, DX 12 and Vulkan.
Is a single context SFML possible? Yes, but not easily. As soon as you have multiple windows, there needs to be a way to target them for drawing. On Windows and Unix, you have the concept of a device context and drawable respectively. On OSX the targeting is done through an NSOpenGLView in a similar way. When activating a window's context, SFML goes ahead and changes the target for drawing to point to a new window as well. It doesn't have to change the context and could just as well reuse the previously active context to draw to the new window, but Laurent decided to just give each window their own context. This was probably necessary because of the "there is always an OpenGL context active on every thread" mantra. In a single-context model, we have stricter requirements. The context becomes a shared resource, meaning that we need to acquire it when we need it and we need to release it when we are done using it. This is doable in sfml-graphics code, but the user would also need to respect the model when acquiring the context to perform their own GL operations. If they forget to release the context, SFML would no longer be able to use it and everything would break. From a user-friendliness point of view, single-context would be less user-friendly than the current implementation, but that would really only affect GL users who should already be in a different mindset.
I've already tried many times in the past to get rid of any additional contexts and make SFML truly single-context. That is why I know it takes a lot of work and re-writing. No changes to the external API would be necessary, however the behaviour of Context::setActive() would need to be tweaked a bit.
