Regrettably, achieving this without prior knowledge of border widths is not feasible. If the border widths are unknown or dynamic, then it becomes quite challenging to accomplish.1
The space within an element's containing block is specifically defined as the padding edge of the element that creates the containing block. This principle is clearly articulated in the specification, and it serves a deliberate purpose; descendants are generally expected not to extend beyond the boundaries of their container unless the container has an overflow: visible property without establishing a BFC (and even then, the impact is purely visual and does not affect layout). Otherwise, the concept of a border loses its significance.
In cases where you want elements to interact based on their borders or outer edges, arranging them as siblings rather than ancestors and descendants is preferable. At the very least, they should be considered unrelated entities2.
This appears to be an oversight; the interpretation of top: x% ought to rely on the parent element's box-sizing value...
The function of box-sizing is to alter how a box's size is computed (i.e., whether the padding or borders contribute to the dimensions specified by width and height); although it can modify the size of an element's padding box, the area of the containing block, if one exists, is still determined by that padding box.
1 This issue could potentially be resolved using custom properties, provided that the same custom property is assigned to both the parent's border width and the child's respective offsets, essentially emphasizing the necessity of knowing the border widths beforehand or having some level of control over them.
2 Floats, for instance, exhibit a strong inclination towards the border edge of boxes, to such an extent that they might seemingly collapse margins in situations where such behavior would not typically be anticipated.