In Australia we are moving to a new datum, GDA2020. The previous datum, GDA94, was for all intents and purposes identical to WGS84 so if the user forgot to set a transformation the data would still align. With GDA2020 there is an approximate displacement of 1.8m, so in order to reduce risk it's important that as much of our Australian data is in GDA2020 as users aren't infallible when it comes to setting transformations.
Easy I thought, just create a new feature service in GDA2020 with the transformations already built in, so that the SDE source layers (in WGS84) will be available in GDA2020. As the SDE source layers are global, they need to be kept in WGS84 so can't be transformed to GDA2020. This is where things unravel.
As shown below, ArcMap will honour the GDA2020 service spatial reference for both map and feature services. Pro will honour the GDA2020 service spatial reference for the map service.


Pro will not honour the GDA2020 service spatial reference for the feature service, instead it uses the source spatial reference WGS84.

So feature services in Pro is the anomaly when it comes to spatial reference. This anomaly appears to be "as designed" by Esri Inc, as recorded in this bug https://my.esri.com/#/support/bugs/BUG-000134342. The alternate solution is to reproject the data source, which is not practical. Strangely the status is non-reproducible.
So my ArcGIS Idea is to have Pro use the service spatial reference like it does for map services, instead of the source spatial reference. Or at least provide the option of using either service spatial reference or source spatial reference.