PROJCRS["Monte Mario / Italy zone 1",
    BASEGEODCRS["Monte Mario",
        DATUM["Monte Mario",<br>
            ELLIPSOID["International 1924",6378388,297,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]]],
    CONVERSION["Italy zone 1",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",9,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",1500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],<br>
            LENGTHUNIT["metre",1]],
    AREA["Italy - west of 12°E"],
    BBOX[36.53,5.94,47.04,12],
    ID["EPSG",3003]]

GEODCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    AREA["World"],
    BBOX[-90,-180,90,180],
    ID["EPSG",4326]]

PROJCRS["WGS 84 / UTM zone 32N",
    BASEGEODCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]]],
    CONVERSION["UTM zone 32N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",9,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    AREA["World - N hemisphere - 6°E to 12°E - by country"],
    BBOX[0,6,84,12],
    ID["EPSG",32632]]

1. ESRI WKT: a dialect widely adopted by ESRI proprietary software.
2. GDAL WKT1: a dialect historically supported by the open source GDAL library.
3. WKT2:2015: as defined by ISO 19162:2015 standard specification (now superseded).
4. WKT2:2018: as defined by the more recent ISO 19162:2018 standard specification .

Concepts to keep well in mind

• forget the old proj-strings; they are no longer the best way for taking full profit from PROJ.6
• the best way to make the most of PROJ.6 capabilities is by leaving the library fully free to choose the best possible transformation from the origin and the destination CRSes.
  but this strictly requires that the library will be backed up by its own private database.

Additional concept

• srid, auth_name, auth_srid and ref_sys_name columns are still required in order to define all supported CRSes and to support relations based on Primary and Foreign Keys.
• but columns proj4text and srtext are now practically useless, because PROJ.6 is now capable to fully define any CRS by directly querying its own private database.
• Future Forecasts: both proj4text and srtext will be probably removed in some future version of SpatiaLite.
  For now they continue to be supported mainly to the benefit of previous versions of SpatiaLite being based on the now superseded PROJ.4

projinfo -s EPSG:4326 -t EPSG:32632 -o proj

• the optional argument area may be NULL (default setting).
  Otherwise it's expected to contain a valid Geometry in SRID=4326 (long/lat). When an area of use is explicitly supplied, then PROJ.6 may eventually use the corresponding BBOX for finely tuning the more accurate transformation.
• the optional argument method is expected to contain one the following values (auth_name:auth_strid will be always assumed as the default setting):
• proj4text: both CRSes (origin and destination) will be defined by passing to PROJ.6 the traditionals proj-string definitions for the corresponding SRIDs retrieved from column proj4text in Table spatial_ref_sys
  This exactly corresponds to the well extablished traditional behavior of all previous versions of libspatialite and still continues to be supported, but isn't any longer the best way for taking full profit of the more advanced capabilities of PROJ.6
• srtext: both CRSes (origin and destination) will be defined by passing to PROJ.6 the WKT definitions for the corresponding SRIDs retrieved from column srtext in Table spatial_ref_sys
• auth_name:auth_srid: both CRSes (origin and destination) will be defined by ignoring the definitions stored in spatial_ref_sys and leaving PROJ.6 free to retrieve their corresponding definitions from its own private SQLite database.
  Note: this method will always take full profit of the more advanced capabilities of PROJ.6, even when using some SpatiaLite database created by earlier versions not yet supporting PROJ.6
• proj_string: an user-defined proj-string (may be one definining a transformation pipeline) will be passed to PROJ.6; this is an advanced option reserved to skilled power users.
• the optional argument proj_string may be NULL (default setting).
  Otherwise it's expected to contain a valid PROJ.6 transformation string, may well be corresponding to an user-defined transformation pipeline. Meaningful only in the case of method=proj_string

Notes

• SpatiaLite does not constraints you in any way and fully respects users freedom carefully avoiding auto-magical assumptions.
  • The new extended signatures supported by ST_Transform closely mimic the most recent PROJ.6 API, so you are free to define your coordinates transformations in several different ways.
  • The default behavior of SpatiaLite when using PROJ.6 is to completely ignore the CRS definitions stored within the internal table spatial_ref_sys
    Any required CRS definition will be always retrieved form the private SQLite database supporting PROJ.6 (method=auth_name:auth_srid).
  • If you have any good reason suggesting to do such a thing, you are anyway free to use the proj-strings (method=proj4text) or the WKT definitions (method=srtext) stored into the internal table spatial_ref_sys table.
    But this is under your full responsibility, and you must be well self-conscious of what are you doing.
• SpatiaLite encourages and promotes the most creative uses of PROJ.6, this including transformation pipelines.
  Correctly using method=proj_string for computing custom transformations isn't necessarily simple and easy, but it's a big opportunity for all skilled and talented power users.

using projinfo for detecting transformation pipelines and supported areas of use

projinfo -s EPSG:4326 -t EPSG:3003 -o proj --spatial-test intersect
Candidate operations found: 3
-------------------------------------
Operation n°1:

unknown id, Inverse of Monte Mario to WGS 84 (4) + Italy zone 1, 4 m, Italy - mainland

PROJ string:
+proj=pipeline 
+step +proj=axisswap +order=2,1 
+step +proj=unitconvert +xy_in=deg +xy_out=rad 
+step +proj=push +v_3 
+step +proj=cart +ellps=WGS84 
+step +inv +proj=helmert +x=-104.1 +y=-49.1 +z=-9.9 +rx=0.971 +ry=-2.917 +rz=0.714 +s=-11.68 +convention=position_vector 
+step +inv +proj=cart +ellps=intl 
+step +proj=pop +v_3 
+step +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl

-------------------------------------
Operation n°2:

unknown id, Inverse of Monte Mario to WGS 84 (2) + Italy zone 1, 4 m, Italy - Sardinia onshore

PROJ string:
+proj=pipeline 
+step +proj=axisswap +order=2,1 
+step +proj=unitconvert +xy_in=deg +xy_out=rad 
+step +proj=push +v_3 
+step +proj=cart +ellps=WGS84 
+step +inv +proj=helmert +x=-168.6 +y=-34 +z=38.6 +rx=-0.374 +ry=-0.679 +rz=-1.379 +s=-9.48 +convention=position_vector 
+step +inv +proj=cart +ellps=intl 
+step +proj=pop +v_3 
+step +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl

-------------------------------------
Operation n°3:

unknown id, Inverse of Monte Mario to WGS 84 (11) + Italy zone 1, 10 m, Italy - Sicily Strait west of 13°E

PROJ string:
+proj=pipeline 
+step +proj=axisswap +order=2,1 
+step +proj=unitconvert +xy_in=deg +xy_out=rad 
+step +proj=push +v_3 
+step +proj=cart +ellps=WGS84 
+step +proj=helmert +x=230.47 +y=56.08 +z=-22.43 
+step +inv +proj=cart +ellps=intl 
+step +proj=pop +v_3 
+step +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl

• The best mode for taking full profit from PROJ.6 is by using method=auth_name:auth_srid (that is the default setting).
  This way you'll be absolutely sure that the most recent and fully detailed definitions will be always retrieved from the PROJ.6 own database completely ignoring any definition (may be incomplete or obsolete) eventually stored into the spatial_ref_sys table. This is a particulary useful option when processing older databases being created by earlier versions of SpatiaLite not yet supporting PROJ.6
• SpatiaLite does not constraints you in any way and fully respects users freedom carefully avoiding auto-magical assumptions.
  If you have any good reason suggesting to do such a thing you are anyway free to use the proj-strings (method=proj4text) or the WKT definitions (method=srtext) stored into the spatial_ref_sys table.
  But this is under your full responsibility, and you must be well sure of what are you doing.
• SpatiaLite encourages and promotes the most creative uses of PROJ.6, this including transformation pipelines.
  Correctly using method=proj_string for computing custom transformations isn't necessarily simple and easy, but it's a big opportunity for all skilled and talented power users.

• new_path: a relative or absolute pathname leading to a valid PROJ's SQLite database.

• auth_name and auth_srid identify the intended CRS.
  auth_name can be NULL, and in this case EPSG will be assumed.
• the optional argument style determines which specific WKT format should be adopted, and must be one between GDAL, ESRI, ISO-2015 or ISO-2018 (this latter being the default setting).
• the optional argument indented if set to TRUE will nicely format a multiline WKT expression, otherwise a single monolithic line lacking any white-space or new-line will be printed (the default is TRUE).
• the optional argument indentation determines how many white-spaces are to be used for indenting (only meaningful if indented=TRUE; the default values is 4).

• wkt_expr: the WKT expression to be evaluated.

• filename: the absolute or relative path leading to some Shapefile.
  Note: exactley as required by ImportSHP() filename must omit any .shp, .shx, .dbf or .prj suffix.

• Short conclusion: installing the software alone is not enough.
  The PROJ.6 private database proj.db must be properly installed as well, in order to ensure that anything runs smoothly.

1. the first place where proj.db will be searched is the same folder form where the EXE binary was initially loaded.
   Example: assuming that you are currently executing C:\myprogs\spatialite\bin\spatialite.exe
   • then an attempt will be made to connect C:\myprogs\spatialite\bin\proj.db
2. a second attempt will be made on behalf of the Public folder.
   Example: an attempt will be made to connect C:\Users\Public\spatialite\proj\proj.db
3. a third (and last) attempt will be made on behalf of the User folder.
   Example: an attempt will be made to connect C:\Users\sandro\spatialite\proj\proj.db

An useful diagnostic check

SELECT PROJ_GetDatabasePath();

• if NULL is returned, then PROJ.6 is definitely unable to connect to its own private SQLite database proj.db
  You have to carefully verifiy that it's really installed on one of the expected standard locations.
• otherwise the path leading to the currently connected proj.db will be returned.

• export "SPATIALITE_PROJ_DB_PATH=/home/sandro/aux/proj.db"
  echo $SPATIALITE_PROJ_DB_PATH
  spatialite

• SET SPATIALITE_PROJ_DB_PATH=C:\Users\sandro\aux\proj.db
  echo %SPATIALITE_PROJ_DB_PATH%
  spatialite_gui