As we know there is the intention to replace the gmt_proj.c projection machinery by the proj4 library. But this move is a big step and will require a lot of work and time. Meanwhile I would like to propose an interim step: to create a translation layer between the proj4 syntax and the GMT -J<...> one. Because GMT does not support all proj4 projections nor does direct conversions from projection_A to projection_B, this layer will forcedly be limited to what GMT can do. But this still covers quite a lot of cases.
What are the advantages of this layer? I can see some reasons.

1. Internet is full of examples of proj4 strings for the most common translations.

2. Many grids have embedded their reference system as proj4, or WKT string that we can convert to proj4 via our GDAL bridge (we already do that in some modules).

3. Even better, never tried but I'm convinced it's possible, we would be able to use EPSG codes directly. The basis for my optimism is that one can convert from epsg to proj4 via GDAL and than convert that proj4 string. Telling the users that they can do -J+epsg:3763 directly (if the XXXXX is covered by our syntax ofc) would be a nice selling point.

But while the -J+epsg:XXXXX syntax is a simple and attractive one, the use of the full proj4 turns out lengthier. For example

-J"+proj=tmerc +lat_0=39.668258333333333 +lon_0=-8.133108333333333 +k=1 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs +towgs84=0,0,0"

but this is an issue that will face anyway when the true to proj4 lib migration will happen.

The other thing is the map scale. Currently in -J, the map scale is the last entry after a '/'. Question:

Should we keep it that way? e.g. -J"+proj=tmerc +lat_0=..."/scale or would it better go into a separate option?

Finaly, r18536 already implements a toy example with Mecator. With it (need to build with -DPRJ4) we can do -J"+proj=merc +lon_0=-10"/8c or -J+proj=merc/8c