TLDR: They're not the same. The reported equality is the result of
approximations and is only true in limited circumstances. GDA94/2020
co-ordinates are defined on different datums and reference frames. The
appropriate transformation between them depends on the level of accuracy
The issue here is the assumption in the question that proj.4 correctly reports the two CRS (co-ordinate reference system) as being the same. They're not. The proj.4 strings quoted aren't the CRS definitions. They're generated from the CRS definition, and the proj.4 strings aren't the full picture. The EPSG registry definitions give us the extra information we need to understand what's really going on.
This stems from a world-view that WGS-84 is 'the' global datum and historically proj.4 has used it as a go-between when converting between datums. Thing is, WGS-84 gets redefined every few years (we're at G1762 now, aligned to ITRF-08) as it's re-aligned with changes in the ITRF reference frame, from which GDA is also derived.
This has lead to these shortcuts and assumptions being baked into proj's behaviour, though in recent versions this is starting to change.
Tracking the implications of changes to reference frames, and when they changed wasn't a big deal while consumer GPS was >5m accuracy but times are changing and sub-metre accuracy requires tools properly account for them.
So, to answer the question we need to trace what datum and reference frames GDA94 and GDA2020 CRS are based on and then see what available transformations there are.
EPSG:7844 GDA2020 2D Geographic CRS (Lat/Lon), from
EPSG:7843 GDA2020 3D Geographic CRS (L/L/H), from
EPSG:7842 GDA2020 3D Geocentric (ECEF X/Y/Z), all of which use
- EPSG:1168(datum) - Geocentric datum of Australia, 2020
EPSG:1168 defines it's anchor reference frame:
- Anchor Definition : ITRF2014 at epoch 2020.0
- Realisation Epoch : 2020-01-01
If you do the same for GDA94 you'll see that the reference frame is ITRF92, aligned on 01/01/1994.
If transforming between ITRF02/14 and GDA94/GDA2020 data, the datums are aligned, and the transformation between them is
null only on the epoch alignment date. That's essentially what those proj strings are saying. For convenience, we don't generally like having to constantly change the co-ordinates we store, so it's simpler to step change the drift between them every few years and accept a level of error.
For most applications requiring >1m accuracy, that's good enough.
But reality doesn't step change every few years and if we want a more accurate transformation, we need to consider the time-dependent distance drift of the datums before/after their alignment. It's a 4D rather than 3D transformation.
The transformations between GDA2020 and WGS-84 or ITRF2014 are described in:
- GDA2020 to WGS 84 (G1762) (1) - EPSG:8448
- ITRF2014 to GDA2020 (1) - EPSG:8049
If transforming between GDA94 and GDA2020, things are simpler as we only need to know the difference between the reference frames. Sort of. There's more than one, and the correct one to use depends on when, how and where the data was referenced to GDA94. It's an attempt to shake out errors due to less refined methods being used in the 90's.
- Conformal - Coordinate Frame rotation (1) - EPSG:8048
- Localised distortion (2) - EPSG:8447
- Conformal - NTv2 Grid transformation (3) - EPSG:8446
To understand under what circumstances these should be used, read the GDA2020 technical manual