One should not try to modify schema through /alter if they are specifying schema through GraphQL. If one is using only DQL, then only they should use /alter. If they are using GraphQL, then they should use only the /admin/schema endpoint to modify the schema. Both of these endpoints together are not supposed to be used because they serve different purposes.
So, when someone initially provides GraphQL schema through /admin/schema, and then they are using /alter to modify the generated DQL schema, then it is up to them to ensure the correctness of the schema. I would call them an advanced user. GraphQL works on top of DQL, so if underlying DQL schema is changed, then GraphQL may not work.
Now, the behavior we are observing is for DQL schema, and to me, it seems correct for the case when you delete a DQL type, and the predicates inside that type are not deleted. Because, as @martinmr pointed, a predicate can be shared across multiple types from DQL perspective. And, DQL doesn’t even mandate one to have types, one can just have predicates, and use them to store their data, without having any types. So, predicates are independent of the types they are in.
Now, this isn’t fully correct:
Even in GraphQL, we have a @dgraph(pred: "predName") directive, which one can use to specify the name of the underlying DQL predicate for a field in GraphQL schema. So, even in GraphQL, one has the capability to share a single predicate across multiple types.
Now, for the 2nd case, when one deletes a predicate in DQL schema, then it is still remaining in the DQL type that was using the predicate. This seems somewhat unexpected behavior because a type can’t be independent of the predicates it contains. A type is composed of predicates, and this is what should be corrected if needed. But, I am not entirely sure if there is a reason behind this behavior in the first place.