Are there any feature comparisons on Direct3D 11 and the newest OpenGL versions?
Well, simply put, Direct3D 11 introduced three main features (taken from Wikipedia):
Now I'm wondering, how does the newest versions of OpenGL cope with these features? And since I have this feeling that there are features that Direct3D lacks from OpenGL's side, what are those?
When one talks about OpenGL and D3D "features," one could be referring to either:
For example, a programmable tessellation pipeline is something the hardware generally has to support (let's ignore, for the purposes of practicality, that an API could in theory implement missing hardware features in software as that's generally too slow to be of real use). Presupposing it does, you can gain access to that pipeline in both D3D and OpenGL. D3D builds the interfaces for doing so into the core API of D3D11 via the hull/domain shaders and tessellation APIs. OpenGL provided an extension that was eventually promoted to part of the core API. When it comes to hardware features, OpenGL and Direct3D are generally equivalent in terms of what you can make the hardware do via either API. The differences come in how.
There are hundreds of small API features (unrelated to actual hardware capability) that differ in both APIs. It's not practical to list them all in an answer. Aside from the fact that D3D is a "traditionally COM-like" API and OpenGL is a "traditionally C-like" API, one of the biggest differences in the feature set is that OpenGL has its rich extension mechanism (and D3D has no such thing). This tends to mean that OpenGL is in theory more flexible and adaptable to new capabilities, at the cost of being slightly more cumbersome to use (thus the plethora of OpenGL extension assistance APIs like GLEW).
Taken from Wikipedia, too: there aren't many differences. Strictly speaking, OpenGL is usually slightly behind Direct3D in terms of features, because the standardisation takes time. However, many of these features are available as OpenGL vendor-specific extensions first, then in the standard itself after some time.
As for your last question, in my opinion, the features that Direct3D lacks the more are a Mac OS X version, a Linux version, an Android version, an iPad/iPhone version, and a PlayStation 3 version :-) (while the last three platforms actually support OpenGL ES rather than OpenGL, it makes porting software a lot easier than porting Direct3D to OpenGL ES)
The other answers (Sam and Josh) cover most of what you need to know, but just adding a few extra points.
Before that however, Josh's point about the API not offering features is worth repeating. It's quite incorrect to say things like "OpenGL has vertex buffers" or "D3D has shaders", and was just as incorrect back in the day when you used to read things like "D3D doesn't have a stencil buffer" or "OpenGL has polygon offset". Your gfx hardware has features and the API exposes them; if your gfx card doesn't have a feature no amount of exposition in the API will give you it (unless you use some form of software emulation, which you really don't want to do) and if your gfx card has a feature but the API doesn't support it then you can't use it either.
Moving on with the extra stuff.
D3D has more sensible management of multiple monitors/multiple gfx cards, which can't be underestimated with some end-users.
Explicit memory pools in D3D9 or below were nice (aside from the dreaded D3DERR_DEVICELOST) and it's vertex buffer API is much cleaner and clearer and easier to use. Separation of layout specification from data specification was the right decision IMO. GL has improved with attrib arrays and VAOs but it's still not all the way there.
D3D also guarantees a single consistent shader compiler for all users and on all hardware, whereas each GL implementation has a different shader compiler. The Effects framework is also very nice.
D3D generally has better quality drivers than OpenGL. That's pretty critical.
OpenGL has extensions. That's something of a double-edged sword, as while you can get access to newer vendor-specific features earlier, you may end up with a mess of multiple codepaths all doing broadly the same thing. You make your own choice about which side of that tradeoff you're happier to accept.
OpenGL still has some nice things that D3D is missing. The accumulation buffer (on hardware that accelerates it) can do some neat things; D3D11.1 is apparrently finally going to get logic ops on the framebuffer.
glCopyTexSubImage is very nice in cases where it's implemented properly (which should be everywhere as Doom 3 used it) and D3D has no direct equivalent, to pull another specific example out.
OpenGL is capable of providing software fallback for things required by the spec but unsupported in hardware (not all things however) whereas D3D will normally give you a big ugly crash or error. Another tradeoff where you decide (although I still have nasty memories of a Geforce FX - which supported NP2 textures as required by the GL 2.0 spec - going back to full software emulation without warning if you actually tried to use one...)
OpenGL tends to maintain backwards compatibility through revisions of the API (I'm ignoring core contexts here) whereas D3D does not. There are arguments for and against each philosophy that it's probably not appropriate to retread here; just something to be aware of.
OpenGL still has bind-to-modify whereas D3D does not; you operate directly on the object (or pass it as a param) instead. The OpenGL way tends to mess up any state filtering you might be doing, IMO.
They're the main big ones I can think of right now; nothing too earth-shattering but enough to tip a decision.
Finally, it's also incorrect to state that Android, mobile devices, the PS3, etc use OpenGL, because they actually don't. They use GL ES which is in some ways a subset of full OpenGL and in other ways quite different (and on the PS3 anyone concerned about performance uses libgcm anyway).
