Construct 2 will definitely be OpenGL rendered, and there will be no DirectX renderer, at least not at first.
DirectX 10 and 11 are not at all an option since so many people are still on XP (roughly two-thirds of all computers still use it). That leaves the choice between DirectX 9 and OpenGL. Features and performance are pretty much equivalent, so that's not part of the choice (although OpenGL can bring DX10 and DX11 features to Windows XP!).
Cross platform is an important point, allowing the opportunity for games to run on OS X, Linux, PS3 etc without rewriting the renderer. But there are two things which make it a far better choice for Construct! OpenGL games are much easier to redistribute - OpenGL 1.1 comes preinstalled on Windows XP, so there's no need to update DirectX or install those damn "optional" updates that are actually required. So more often than not you send someone a game and it will just run, like it should.
OpenGL is also MUCH easier to program for! I also don't know where the idea DirectX is easier came from. It is far, far more complicated, and also dumps some extremely tough problems on the developer (like lost devices). If I had a blog this would definitely make for a rant. Let me briefly cover it here anyway.
Lost devices are when something happens to the fullscreen display, eg. something else goes fullscreen (like previewing a fullscreen game in Construct), or the computer going to sleep mode, or a fullscreen application being alt-tabbed away and restoring to the desktop. A similar problem happens if you want to resize the window. In DirectX, the application gets sent a message that says "boom, lost device, everything your program has done in DirectX has now been reverted". You now have to completely re-load the application's textures, effects, fonts, states... everything. In the editor where people preview fullscreen games, this happens regularly, and is extremely complicated to handle, not to mention the runtime also has to handle it.
OpenGL has no notion of lost devices and handles it all for you.
Ordinary drawing in DirectX also involves a number of steps. First you have to specify a vertex format, and define in the program a correspondingly formatted structure. Drawing a quad (a rectangular shape, eg. a sprite) involves sending to the graphics card four vertices (the corners of the box). So to do this first you create a vertex buffer, with room for four vertices allocated. You lock it, copy in four of your structs that define the four corners, and unlock it. For maximum efficiency you must also create an index buffer, with six indices, to define two triangles that draw the quad. However, for maximum efficiency, both index and vertex buffers must be as large as possible, ie. contain data for as much drawing as possible when sending them off. Because in Construct draw calls can come from all over the place (lots of different plugins render stuff), this means implementing a batching system that collects as many rendering calls as possible, generates two very large vertex and index buffers, then sends these to the GPU with a clever batch executor that runs through the saved rendering commands executing them on their associated vertices and indices. For maximum efficiency (again) you'd need to write a custom allocator (and Construct does in fact implement one), because you don't know how many rendering commands there will be, so there are thousands of small allocations every tick, so the allocation must be as optimal as possible. The code for this optimal DirectX renderer is extremely complicated and runs in to pages and pages of code with many past bugs associated with them.
Here's how you draw a quad in OpenGL:
glBegin(GL_QUADS);
glVertex3f(0,0,0); // top left corner
glVertex3f(1,0,0); // top right corner
glVertex3f(1,1,0); // bottom right corner
glVertex3f(0,1,0); // bottom left corner
glEnd();[/code:2q69wpxs]
You might also notice this essentially naturally is a batching system. Just don't call glEnd(), unless the next drawn thing isn't a quad. It's [i]trivial[/i], especially compared to the monolithic system required for DirectX.
Why should end users care about how easy it is to program though? Well, it saves hours of developer time, allowing us to work on other features and fix other bugs instead, and results in fewer bugs, because the program is simpler.
Having coded a bit for OpenGL recently I have to say: I genuinely have no idea how DirectX rose to prominence. Any developer who tried both would simply use OpenGL because it is so much easier and has lots of benefits like multiplatform (one of those platforms being XP!). I guess the situation the world over is like myself, using DirectX just to go with the flow since lots of big games also use it. I guess it's testament to the genius of the Microsoft marketing department that they managed to make a complicated API which poses you with nasty problems the world's most popular graphics API. </rant>