In passing, would it be appropriate and/or useful to suggest
improvements to [the envsys(4)] API? When I was writing code, I
found the envsys(4) ioctls to be deficient for my purposes.

[Paul Goyette]

I'd be interested in knowing in which ways you found the current API
lacking. [...]

Well, some things are underdocumented. For example, it seems that most
sensors are not in the units specified by envsys_tre_data_t.units, but
rather in 1e-6 of that unit - for example ENVSYS_SWATTHOUR sensors are
not in watthours but in microwatthours - and, as far as I've been able
to find, this factor of 1e6 is not documented anywhere but the source
to envstat(8). Except for temperature, which is specifically said to
be in microKelvins. But others are said to be in volts, amps, etc. To
quote both the envsys(4) and <sys/envsys.h>,
union { /* all data is given */
uint32_t data_us; /* in microKelvins, */
int32_t data_s; /* rpms, volts, amps, */
} cur, min, max, avg; /* ohms, watts, etc */
/* see units below */

This is greatly cleaned up in the envsysV2 implementation.

If the "micro" is supposed to apply to all those units, not just
Kelvins, then (a) "rpms" needs to be removed from the list and (b) the
wording needs to be improved.
But the one piece I've found so far that isn't just a lack of
documentation (well, unless there are totally undocumented calls) is
that there's no way to fetch multiple sensors' values without potential
for skew between them.. For example, to quote from the code I've been
developing,

In envsysV2, a single call is used to retrieve the whole set of sensors
(in a prop dictionary) so you don't need to worry about skew caused by
userland sampling. Of course, there is still the possibility of skew
caused by the driver's need to fiddle with hardware registers.