The correct way to update the API in lock-step is to retain our G unit (can't remove from the Rust API without a breaking change, but no need to because the deprecations work well), introduce a marker in riot-sys that forwards the information whether this particular change has landed in the underlying RIOT, and then use the marker to decide whether the conversion to RIOT uses the old or the new names.

How convoluted this is (precisely: That this spans across two crates) indicate I should try to make the workflow smoother; defining the markers where they are used (as opposed to where the source code is processed) should help simplify this.

I'll have a brief look into whether that simplification can be done easily already, or whether that's better done later.

It seems to be straightforward enough to do the simplification now; RIOT-OS/rust-riot-sys#21 is pending its build tests. With that, the marker check can be introduced in riot-wrappers; still preparing a PR that'll set the style and add the 10-ish lines of infrastructure.

Then, riot-wrappers' build.rs should check for the presence of UNIT_G_FORCE, tell rustc to set the config "marker_unit_g_disambiguation", and then the aliases can be configured appropriately.

Do I understand the status of #19292 right that this PR is not needed any more to make things work there (because there are now enum aliases instead of preprocessor redefines)?

AIU we should still do something here (basically, follow there renamings), but now it's "only" about evolving the Rust API.

Yes. I intent do migrate to SenML units for phydat anyway. Especially for when dumping to JSON, the SenML unit have a clearly defined string identifier. Whereas the current unit strings are clearly targeting human audience, rather then being optimized for being machine readable.

Closing in favor of #50