Bit of an update. By grabbing the NOAA ENC for Boston Inner Harbor (https://charts.noaa.gov/ENCs/Agreement.shtml?US5MA11M), I can reproduce this with the AddEncExchangeSet example.
*Currently*, I cause the failure by toggling between `shallowDepth = 1.8` and `shallowDepth = 1.81`.
Curious, I went back to the NOAA ENCOnline viewer. It turns out that this display issue is reproducible in their online viewer as well. What's strange is that it's highly dependent on the exact values.



I'm not a big believer in coincidences. 1.80m = 5.906ft, 1.801m = 5.909ft, so there's no magic threshold being crossed in another unit system.
Playing around, I realized that 1.81 becomes valid once the safe depth goes above 3.6.


This might be a NOAA or S-57 thing, where 0.30m is approximately 1ft (although 1.8m is 5'10 3/4", not 6ft!), and all data is being forced into the closest foot bucket. That would be wrong, but considering the imprecision there might be nothing which can be done about it.
Likewise, with the ENC provided sample dataset, it looks like the settings have a similar effect, but for a different range of values. I'm beginning to think that what I'm seeing is an interaction with some underlying feature of the dataset which is subtle but relevant. (I'm learning here, so apologies for not understanding the full extents of the ENC's backend.)
Where this is a problem and winds up displaying bug-like behavior is with unit conversion. As my app's backend is in standard units, I convert any non-standard user units (feet or fathoms) into metric. So if a user inputs 5' 11" as the keel depth, this gets converted into 1.8034m.
P.S. This still doesn't explain the inconsistency I saw in my app, but I'm willing to chalk that up to make_clean hiccups.