__kindof type specifiers allow the developers to express their intent in discriminating between generic type arguments being matched exactly or allowing sub-types. When generics were introduced, it was already too late to add __kindof specifiers consistently across all the code. So for now in most code we believe it's all right not to have them, but we need to expect to have them at least in some places (which would normally be API declarations) and pick them up when they're present by loosening our dynamic type information from non-__kindof to __kindof, which would suppress some of the false "invalid cast" warnings.
In the test provided, the __kindof is only present on the API return value; direct cast from the object created within the callee function is an error, however casting indirectly through a __kindof type should be possible, because just one __kindof annotation at the API declaration is considered to be enough to express the intent of "it was __kindof from the start but we didn't bother adding it".
For now, we discard the original type information when we find __kindof specifiers in a chain of casts.
I am concerned that this might cause regressions as other logic in this function is not triggered when this condition fires. For example, this would only be safe if Current and StaticUpperBoound are the same type apart from __kindof modifier.