Thanks for the bug reports Corey, there are two separate things going on here.
The easy one first, some time ago while I was refactoring our GrStyledShape class, an explicit round rect switched to defaulting its dashing from index 0. SkPaths created from a round rect (e.g. SkPath::addRRect, etc.) have been historically defined to use index 6 or 7 depending on the direction of the verbs. The CPU backend always just converts shapes to paths so remained consistent. I have a fix for the starting position of the dashes here: https://skia-review.googlesource.com/c/skia/+/698218
The second has to do with numerical stability, tiny path sections, and winding rules of strokes vs. fillls. See https://bugs.chromium.org/p/skia/issues/detail?id=13030
for a bit more context. Basically, when we do a perpendicular sweep line to form the stroke, and the path has high curvature relative in a small area relative to the stroke width, the sweep line pivots about itself. For a rounded rect with a 1px corner, it's doing a 90 degree turn very quickly and creates the quarter circle on one quadrant and a swoop cutout on the other. Even if you changed the verb/point construction of the path to get rid of the swoop, the stroking would never cover a quarter circle. This shows up in the dashing because the on interval happens to end right at the end of the rounded corner.
Skia doesn't do any munging of dashing intervals to avoid this, and it applies dashing in the original coordinate space and as a separate action from the stroking itself. Without either of those two pieces, it's hard for it to identify parts of the original path and the dashing pattern that would create problematic strokes.
For a case like this, the best workaround I have is to detect that your corners will project to a very small shape relative to the stroke width (in this case I believe it's if the corner radii are less than half the stroke width), and switch to a rectangle with round joins, or clamp the corner radii.