Thanks guys, it would appear my understanding of how this works is limited.
#1: Stop misunderstanding that and implement things correctly instead of using work-around hacks. This will solve all of your problems immediately.
Using a work-around hack is not what I was trying to do and, in fact, that's kind of a contradiction - if I've misunderstood something, it's not really a work-around hack. My c# application is a multi 'view' (by view I mean a panel/control in c# that can display a rendered image from within my c++ engine) app with at least 3 rendered panels, but the option of more. The reason I initially thought to use swap chains is purely by research. Once I'd got my image rendering in a view in my c# client, I resized it and the pixels stretched which I obviously don't want. When I did some further research, I found that you needed to reset the device when changing the size of the rendering area in order that it didn't have to stretch the image across a wider area. Resetting the device, in my mind, meant losing, or decoupling then, my resources. As I have a fair amount loaded into the card and I'd seen other applications manage to resize windows dynamically, I assumed they couldn't be resetting the device and reloading resources constantly whilst the window was resizing, which led me to swap chains.
I read that in order to use swap chains (which at this point felt like the right thing to) I need to render to a back buffer retrieved using the swap chain (which I thought was its own back buffer) created for the view/rendering panel/viewport and then once rendering is done, call Present on that swap chain. What I wasn't aware of is that any additional swap chain created uses the same back buffer. L Spiro, you mentioned that swap chains have their own back buffers - is that by default because it appears that any additional swap chain I create, uses the same back buffer as the device - which does make sense if the idea is that you are rendering to a specified portion of the back buffer - and that would explain the artifacts I am seeing where one rendered view shows flickering bits of the other and vice versa.
So, seeing as I have clearly been mislead by my research or have misunderstood it, let me see if I now understand...:
In my c++ engine, I have the ability to render in full screen mode, windowed mode or to render to a passed-in HWND. I need to create a C# front end which has multiple 'views' in the form of a couple of split containers (front, side, top - style) which will all be rendering the same scene but from different angles. I also need to cater for a floating tool-like window which could very well be floating over the other rendered views.
So from Buckeye's point, I can achieve this by just using the default SwapChain that gets created when creating the device and Presenting to different areas of it (passing in the correct RECT structures to Present()). If I need to have windows floating over the top, I guess I just render them after the ones underneath?
#2: Stop running away from lost devices. The full list of things that can cause the device to be lost is intentionally left unspecified so that people don’t make assumptions as to what can cause it and thus will implement proper handling of such a scenario. It is also trivial to restore resources after a lost device, so there is really no reason not to handle it properly.
I'm not running away from anything. My assumption on this was one of speed after a bit of misled research. Other apps that do this resizing of multiple views can't possibly be resetting and reloading resources dynamically anytime the mouse is moving whilst resizing - I just took the wrong route to working out how that's done.