In a single buffered screen there is just one bitmap. Periodically a snapshot of this bitmap is copied to the screen. The danger is if you happen to be in the middle of modifying the bitmap when it is copied, the screen might receive a partially modified bitmap. Double buffering solves this problem by having two bitmaps, one for the screen and one that can be freely modified without affecting the screen. Only when you explicitly call SwapBuffers (presumably when you've finished a set of modifications) does the modifiable bitmap become available to the screen.
The bottom line is there are very few cases where it's appropriate to use a single buffered screen. Unless you have a very good reason, you should always use double buffering.
No you cannot mix the two. The roScreen has a stack of its own. Everything would have to be done with the use of the 2D interface. There is a learning curve but if your up to it And have the time to learn it then it's quite rewarding. But it does take time to understand and then build your own lists, menus and grids. It's like buying a cake from the store (top level components ) or baking it yourself. The ingredients being the 2D interface objects and functions
The roScreen implements the 2d interface as well as roBitmap and roRegion. All objects that implement the ifDraw2D interface make up the 2d. Along with those objects is roCompositor and roSprite for creating, layering and drawing sprites. A Sprite is simply a specific region of a bitmap that you want to place somewhere on the screen. Since sprites have a Z order they can be layered. The compositor handles the drawing of all its sprites in the Z order defined. roRegion does implement the ifDraw2D interface but is not documented very well.