the issue is the `fork` mechanism of github is not semantically like a `git clone`
it's more like creating a larger git repo in which all forks weather private or not are contained and which doesn't properly implement access management (at least point 2&3 wouldn't be an issue if they did)
there are also some implications form point 1 that forks do in some way infer with gc-ing orphan commits (e.g. the non synced commits in he deleted repo in point 1) at least that should be a bug IMHO one which also costs them storage
(also to be clear for me 2&3 are security vulnerabilities no matter if they are classified as intended behavior)
the issue is the `fork` mechanism of github is not semantically like a `git clone`
it's more like creating a larger git repo in which all forks weather private or not are contained and which doesn't properly implement access management (at least point 2&3 wouldn't be an issue if they did)
there are also some implications form point 1 that forks do in some way infer with gc-ing orphan commits (e.g. the non synced commits in he deleted repo in point 1) at least that should be a bug IMHO one which also costs them storage
(also to be clear for me 2&3 are security vulnerabilities no matter if they are classified as intended behavior)