In modern days of the OSM project - yes, because both most popular editors (in-browser iD and standalone JOSM) are now CRS-aware. I personally uploaded my data in GeoJSON format (stating the correct CRS) without reprojecting it to iD and it displays them with desired accuracy.
But in the “olden days” even a mention of this being an issue was treated by zealous community of amateur enthusiastic uneducated mappers with a lot of pushback, and accusations of gatekeeping, condescension, egotism.
I have a very brief article on the practical handling of data and time-dependent CRS transformations right here Dzertanoj's Diary | An infamous "NAD83 to WGS84" affair | OpenStreetMap but it’s not a tutorial but rather a snapshot of information and tools needed for it.
There’s some information here Transformation tutorial — PROJ 9.5.1 documentation
I like to say: “you can’t outperform your correction source or your antenna”.
But the first step is to Understand your correction source.
U-Blox has a short paper that’s a good start, describing their PointPerfect Service.
It’s Titled : Not just WHERE are you, but WHEN are you"
Point Perfect uses the ITRF2020(current epoch) reference frame.
The coordinates for the Reference Stations for the PointPerfect Service are updated Quarterly.
For Example, the tectonic plate velocity for my location is just under 1.4cm per year to the West.
So for me to accurately describe a position in space, I have to tell you WHEN that position’s coordinates are referenced to [the reference frame and epoch], just like the CORS stations do.
Because next year my pin in the ground will literally move 1.4mm South and 13.5mm West, and at that same rate every year from now on.
Note: The NGS modernization that’s underway right now is derived from ITRF2020, so Americans don’t need to think this “International Frame” won’t apply to us 
I found another, a little more technical description here https://www.eurocontrol.int/sites/default/files/2024-12/eurocontrol-coordinate-reference-systems-basic-user-guide.pdf
It also introduces a lot of special terminology that is commonly used by various official sources.
I think there’s a little confusion about mount points, versions, and SW maps. There are two versions of NTRIP. Anything professional will surely work when treated as v2, and will likely also work in v1 compat mode. If you have choice I’d just configure 2. That’s not really about SW Maps at all; it’s just your context for running into it.
If you are getting RTK float, that means that refererence data from the caster is making it to your F9P and your F9P is handling the data ok, but that it’s not quite good enough. In that situation, your are not having a v1/v2 problem.
CMR is an old protocol that the F9P doesn’t speak. Ignore it.
You want as many constellations as possible, because the F9P does all 4. You want either the closest base, a mountpoint that auto-chooses the closest, or ideally a network mountpoint that gives you synthetic data interpolated to where you are. Usually operators document this ok, at least for people that understand the big picture.
I would be shocked if any US civil federal or state RTN operated in anything other than NAD83(2011) epoch 2010.0. MassDOT certainly does. It’s the National Spatial Reference System. It’s buggy of SW Maps (and QField) not to be able to label the incoming coordinates with that datum (EPSG:6319), and almost certainly buggy that it would then do a null transform to “WGS84”. It’s also confused to use “WGS84” because it’s an ensemble, and that means you know you are in one of the members but you don’t know which - but lots of standards just say that. Or, the standards mean “in the most recent realization”.
I have transformed from 6319 to ITRF2014 as a proxy for recent WGS84 when uploading RTK data to openstreetmap.
One of the reasons to prefer EPSG:6319 is that station velocities (in most of the US, except CA that’s always unstable for lots of reasons 
are near zero*. With RTK and ITRFnnnn, you really need to attach times to all coordinates, or transform to a common epoch with a plate motion model. 1.4 cm/y over say 2 years will be easily discernable.
Does josm transform epsg:6319 to modern WGS84? Does it transform to the ensemble, or to the most recent member, or ? How does it handle epoch?
Calling NAD83(2011) epoch 2010.0 a 25-year old frame vs “Today’s” is not accurate. NAD83 has multiple members in the ensemble, just as there are multiple ITRF realizations of ITRS. The real point is that modern NAD83 is a static datum (plate-fixed, essentially zero velocities), and that ITRF is a dynamic datum and that one always needs to carry epoch with it.
This is why I think it makes sense for people to use their national/regional plate-fixed datums for observing and storing results, and then transform as needed. Unfortunately that doesn’t work with ITRF-based reference networks, and then you are forced into trying to carry epoch, which is often hard.
@gdt - Please read my entire statement :
A plate-fixed reference frame literally ignores the fact that all monuments are moving at a “somewhat” constant rate…by definition. I personally don’t see any ambiguity in my statement, but maybe so ?
The National Spatial Reference System is leaving NAD83 behind. ITRF2020 will be integrated into all products and services
Per NGS :
The North American Datum of 1983 (NAD 83) and North American Vertical Datum of 1988 (NAVD 88), have been identified as having shortcomings that are best addressed through defining new horizontal and vertical datums. Specifically,
If anyone wants to learn, it’s better to also know where we are headed in addition to where we’ve been.
I don’t dispute the details. The “25 year old” vs “modern” broad brush and then reasoning from that that somehow using ITRF is better is what I objected to. And, a plate-fixed frame does not ignore that the plate is moving. It refers coordinates to the plate instead, so that stations are not moving relative to the plate. It’s not like the ITRF reference frame isn’t moving either, relative to the sun. Using a plate-fixed frame is not a wrong thing to do, and not an old-fashioned thing to do. It remains the best practice for plate-scale precise measurements of marks on the ground.
Yes, NSRS will in some number of years transition to NATRF2022. And yes, that is “based on” ITRF, but it is not a copy of it. There wiill be an euler pole rotation so that… NATRF2022 station coordinates will have very small velocities. It will not quite be plate fixed, but it will be close, maybe even closer than NAD83(2011). My shocked statement was about today. After adoption there will be a transition. I do not expect it to be super fast. I do not expect any state DOT RTNs to operate in ITRF.
Agreed about NAD83 geocenter offset issues. But that’s not really all that relevant when using it for surveying. My real point is that if you are doing precision measurement and storing such data about points on the stable NA plate, I think the best plan is to use NAD83(2011) epoch 2010.0, and I think that this will remain true until the state RTK networks transition to NATRF2022.
Unsaid, but I am also storing heights in NAD83 HAE, because that is what I am observing, and those can be transformed to NAVD88 as needed. But there’s a fair bit of uncertainty in the hybrid geoid model, and keeping them HAE will reduce the errors when they are later transformed to NAPGD2022
Totally agree about the transition period. NGS is a bit behind on their schedule too
But once finalized and adopted, All State’s must use the modernized NSRS. It’s not going away.
[cut/paste from NGS]
Section 2809 of the [Geospatial Data Act of 2018] specifies that all federal civilian agencies that collect, produce, acquire, maintain, or disseminate geospatial data will be required to use the new reference frames…In addition, any state agency or organization receiving funds from the federal government to generate or process geospatial data must conform to the modernized NSRS.
I haven’t looked at the source code, but it definitely is capable of some transformation, I haven’t tested it thoroughly.
I was mostly interested in what the in-browser iD does. It reads GeoJSON with a specified CRS and displays it without a shift specific to null transformation. Comparing the result to manually transformed files, I figured it was likely targeting EPSG:7665. Don’t take it as the ultimate truth; try for yourself with PROJ.