[preface: I write this as someone whose entire career is based on doing computation with Python, and with systems where physical units are critical and complex, and who maintains a fair bit of my own custom unit-oriented code -- this is not hypothesis]

1) It is absolutely absurd to even talk about this without consideration of the scipy community -- there has been some mention, but it seems to have been largely skipped over. I think this whole thread started (Or at least it was mentioned early on) with a note that Python could be THE engineering tool (which now that I say it, was a quote from a Professor of mine from 25 years ago -- applying to MATLAB :-) ) if it included good unit handling. But it's not actually Python that has become so widely used in the engineering/science/data analysis world -- it's the "Scipy Stack" / "numpy ecosystem", whatever you want to call it. 

Along those lines, there was some talk about astropy.units about how they only work with numpy arrays, and that's a limitation -- but it's really not a critical one. The fact is that anything that doesn't work with numpy arrays is dead in the water for widespread use in the engineering/science community. Whereas not working with the built in scalar types is a minor limitation.

2) As for the SciPy community, I've lost track a bit of the current status, but about ten years ago there was a nice talk at the SciPy conference about handling physical units -- the conclusions at that point were:

 * There are a dozen or so libraries to do it 

 * a few of those are pretty darn good

 * there is no obvious "best" one.

Given the continued existence of astropy.units, and pint, and SciMath units, and wrappers around C libs, like udunits, and ..... I think we're still in that state. What does this tell us? Well, the scipy community is full of a lot of really smart people that are trying to get real work done, and tend to be very cooperative: if there was one clear winner, it would have risen to the top by now. Which tells me that unit handling is very, very, hard, and that there may be no one solution that is suitable for all (or even most) applications.

3) I am having a really hard time figuring out why folks think this needs to be built into the language -- having a nice compact and clear literal for  numbers-with-units is great, but really only matters for UIs, interactive use, things like Jupyter Notebooks, and maybe quick one-off scripts. And all those can be handled with some sort of pre-processor -- either in the application, or using the existing import hooks or codec system.

4) I can see the appeal of adding some sort of syntax or something to the language, and then letting third-party libraries actually implement it. But I'm  wary of this -- it reminds me of adding annotations to Python without specifying how they should be used -- and now we've discovered that it really is important to have a standard type system, and in fact, are moving towards breaking other uses of annotations. Let's not go down that path again.

-CHB