Public bugs can be searched by number on https://support.esri.com/en-us/search
Not all bugs are on the public list though; I think they have to be reviewed first, but I am also not super clear on what gets a bug or enhancement moved to the public list.
The attribute table and dynamic text "decimalPlaces" property only changes how the values appear to users - not how they are stored. So if they are only changing what is displayed to users by using a basic round function without accounting for the floating point problem, then users will get unexpected results; like when I had a polygon recorded as 1.15 acres but was showing as 1.1 acres when set to one decimal place in the dynamic text tag for a map. In my use case, I need the "rounded" values to be displaying the results of a typical round up operation and not a literal round on a floating point approximation.
The Arcade round function addresses the floating point problem - that's why there's a mismatch between what gets labelled using Arcade round() and what gets shown in the attribute table with the same number of decimal places. Additionally, whatever language/bit of code is handling the decimalPlaces property in ArcGIS Online is also handling the issue and rounding up as you would expect. The inconsistencies between label and attribute table and the operation of the "decimalPlaces" property between ArcGIS Pro and ArcGIS Online very much seem like a bug to me.
There are several programmatic methods to "round" a floating point value to display to users of a software that better matches the intent behind a stored value. Several methods are outlined here for C++: https://java2blog.com/round-to-2-decimal-places-cpp/
Also, if the attribute table were consistently being true to floating point values, then when I entered 1.15 into a field set for 6 decimal places, it should show me 1.149999. Instead, the attribute table is displaying 1.15 - so there is already some level of operation being performed when it is showing the "full" value in the table to hide the approximation. Why hide the approximation in the table set to more decimal places than intended but not address that same issue when "rounding" to fewer decimal places?
I've learned my lesson though when I had to change 246 dynamic text tags in 82 layouts to use the Arcade round function instead of the decimalPlaces property. (yes, I desperately wish these layouts could be a map series but there's no effective method I've found for placing insets within a map series that doesn't cause some amount of manual work for each map)
