In other words, embedded designers or stand-alone top-level designers. This argument has certainly served to polarize the Delphi community more than anything else has in recent years. There are those that only accept a "pure" traditional Delphi style designer, there are those that don't seem to care one way or another, and then those that are perfectly fine and somewhat prefer an embedded designer. It seems, however that the Delphi "purists" are the most vocal and vehemently against what they would characterize as "messing with success," by adopting a modal/embedded approach to form design. Personally, I've adapted to using either style and can see some of the advantages that each side has to offer. You might come to the conclusion that since I'm the one that did all the work to embed the VCL designer, I have a vested interest in keeping the designers as purely embedded. This certainly would allow me to focus on making that one mode work the best that it can. However, there are a few items that the embedded designer simply isn't able to address.
The embedded designer makes for a cleaner, more controlled environment. You always know where the designers are located, you are insulated from your co-workers that have screens with laser-printer resolutions placing the design form at some location that is someplace off screen. The designer also can display the border style of the form in the actual style that it will end up being rendered as. And, there is just a feeling that everything is more organized and more "under-control" with the embedded designer. There isn't this haphazard arrangment of windows with all your other applications peeking at you from between the cracks.
In the other camp, there are some things that the top-level "floating" designer does that simply cannot be done as easily with the embedded designer (and by extension, a single-window docked IDE). You can design a form that is at or near the actual screen resolution much easier since there is no "frame-overhead" for each designer. You can arrange the forms in such a manner that you can see several at once, which in the case of inherited VCL forms, is very helpful when modifying an ancestor form so you can see the live-updates on all the descendants and determine if moving the "OK" button will obscure something on any of the descendants. While, personally I prefer to dynamically position the forms at run-time, you can set the form position to "poDesigned" and manually arrange all your forms in the locations in which you want them to appear at run-time. Then there are the issues regarding the more frequent use of multi-monitor systems where developers will use the primary display to position the design-time forms, and use the secondary display for the menus, code-editor, OI, and other design-time/editing support windows.
Now before you start warming up your flamethrowers and start indiscriminately spewing expletives regarding your disdain for one style or another, just understand, that this issue has been heard loud and clear and we are looking into ways to address the issue for a future Delphi product release.