Core And Compatibility in Contexts
OpenGL version 3.0 introduced the idea of deprecation; some sections of the specification could be marked as deprecated. This means that they can be removed from the core specification in later versions, which happened in version 3.1, when the Fixed Function Pipeline was taken out.
However, since many implementations support the deprecated and removed features anyway, some implementations want to be able to provide a way for users of higher GL versions to gain access to the old APIs. Several techniques were tried, and it has settled down into a division between Core and Compatibility
OpenGL 3.1 and ARB_compatibility
A new extension, ARB_compatibility, was introduced when OpenGL 3.1 was revealed. The presence of this extension is a signal to the user that deprecated or removed features are still available through the original entrypoints and enumerations. The behavior of such implementations is defined with a separate, much larger, OpenGL Specification. Thus, there was a backwards-compatible specification and a non-backwards compatible specification.
OpenGL 3.2 and Profiles
When OpenGL 3.0 was introduced, a new context creation mechanism was introduced as well. Since later versions could remove functionality, it was important that the user be able to ask for a specific version of OpenGL, one that they had written their code against.
However, the ARB_compatibility extension posed a problem: the implementation decided whether to define it or not. A user could not request to deactivate ARB_compatibility; it was forced on them. This also meant that the core specification had to be a proper subset of the compatibility specification; the core specification couldn't provide functionality that the compatibility one did not provide.
Thus, another change was made to context creation.
The 3.0 form of context creation did not have the concept of profiles. There was only one form of OpenGL: the core specification. In 3.2, OpenGL was effectively split into two profiles, core and compatibility. An implementation was only required to define core, so compatibility is not guaranteed to be available. However, on most implementations, the compatibility profile will be available.
The 3.2 wording also changed what kind of contexts can be returned, allowing 3.0 and higher versions to be given when not directly asked so long as they support ARB_compatibility or are the compatibility profile of that version of OpenGL. So if you ask for 2.1, the implementation is free to give you 3.2 compatibility; it was not previously free to do this.
Because of the change in wording, the way to detect the changed functionality is to check the extension string. If WGL_ARB_create_context_profile is present, then it uses the 3.2 wording. Otherwise it uses the 3.0/3.1 wording.
A context, of version 3.0 or greater, can be created with the "forward compatibility" bit set. This will cause, for the given profile, all functionality marked "deprecated" to be removed. You can combine the forward compatibility bit with core and compatibility contexts.
For 3.0, this means that all deprecated functionality will no longer be available. This simulates the 3.1 experience.
For 3.1, this means that any remaining deprecated functionality (things deprecated in 3.0 but not removed in 3.1) will be removed. Basically, wide-lines. Also, you're not likely to see implementations offer ARB_compatibility if you pass forward compatibility.
For 3.2+ compatibility, it should mean nothing at all. Since no functionality is marked deprecated in the compatibility profile, the forward compatibility bit removes nothing.
For 3.2+ core, it again means that all functionality that is still deprecated (wide-lines) will be removed.