What you offer is possible, however, if you do this using preprocessor macros, you will end up in a conditional compilation hell. The best option for your approach is to compile into shared libraries, one of which is compiled for obsolete and one for the modern one, and loads the correct one on demand. However, when you approach this direction, you can just hinder the manipulation of the preprocessor and just move the transfer path options to your own compilation units.
Another approach is to choose which rendering path to use at runtime. This is my preferred approach, and I usually implement it through a function pointer table (vtable). For example, the volume rasterizer library that I offer has full support for OpenGL-2.x and modern kernel profiles and will dynamically adjust its code paths and GLSL shader code to match the capabilities of the OpenGL context in which it is used.
If you're worried about performance, keep in mind that literally every runtime that allows you to overwrite polymorphic functions must go through this bottleneck. Yes, it depends on some cost, but OTOH is so widespread that pre-sampling processors of modern processors and the indirect transition scheme are optimized to solve this problem.
EDIT: An important note on what "obsolete" OpenGL is and what not
So, here is something very important, I forgot to write first of all: Legacy OpenGL is not glBegin / glEnd . This is due to the presence of a pipeline with a fixed function by default, and vertex arrays on the client side.
Let me reiterate that: Legacy OpenGL-1.1 and later have vertex arrays! This effectively means that a large amount of code, which is associated with the layout and filling the contents of vertex arrays, will work for the whole OpenGL. The differences are in how vertex array data is actually passed to OpenGL.
In an obsolete pipeline with a fixed OpenGL function, you have several predefined attributes and functions that you use to point OpenGL to memory areas containing data for these attributes before calling glDraw…
When shaders were introduced (OpenGL-2.x or via the ARB extension earlier), they came to the same glVertexAttribPointer functions that are still used with modern OpenGL. And in fact, in OpenGL-2 you can still point them to client buffers.
The OpenGL-3.3 kernel forcibly used buffer objects. However, buffer objects are also available for older versions of OpenGL (kernel in OpenGL-1.5) or through the ARB extension; you can even use them for non-programmable GPUs (which means the efficient first generation Nvidia GeForce) of the last century.
The bottom line is that you can write fine code for OpenGL that is compatible with a huge range for version profiles, and only a very small version code is required to control an outdated / modern transistor.