We do exactly this. We have the following POM parents:
...parent - with the top-level properties, profiles, plug-in declarations, ...
...core.parent - parent for all core bundles - EMF models, debug, log,... - basically stuff that does not use org.eclipse.ui or friends and will be used in both client and server
...client.parent - parent for all client UI bundles (with IDE, BIRT, and many other things)
...client.test.parent - parent for all tests for client bundles
...server.parent - parent for all server bundles (with Equinox, RAP, BIRT Runtime, ...)
...server.test.parent - parent for all tests for server bundles
Each of these currently have their own target platform (except the top-level parent). We do have a number of things that are used for both the client and the server and use UI, but we have compiled these as part of the server as RAP basically is a reduced RCP - we do test these in two test bundles for the client and the server - just to make sure, "everything" works...
Our biggest problem in the development is that it is NOT possible to have a common target platform that can be used in the Eclipse IDE - as it is not possible to combine RCP and RAP bundles - and we would want a separate TP for every bundle anyway... (I think, there are a longstanding Bugzilla on this)...
Also note that the needed test bundles for the target platform differs a little between RCP and RAP, so it does not really make so much sense to try to have a layered approach to target platforms.
So... we have 6 different target platforms - maintained by hand - where two of them are used by the developers (client.test and server.test).
(Actually, we have 8 different target platforms, as we also have the client target platforms based on 4.x as well as 3.x...)