I guess, the underlying reason for this decision was simplicity.
Keep remote and non-remote things separate altogether, don’t let them mix-up because we don’t know when that can be a problem.
If we were not to aim for simplicity, then one would be able to declare a schema like this as you suggested:
interface Post {
id: ID
title: String
# many more fields
}
type CustomPost implements Post @remote {
extraField: string
}
which doesn’t have any non-remote types implementing the Post interface. Which would result in queries being generated for that interface, but no way to add data for it through mutations. Which renders queries useless for that interface.
Apart from that, predicates will be allocated for it and the necessary indexes will be created for it. Which would again be useless.
Also ATM, the way auth queries are rewritten to DQL, they create DQL for every implementing type of interface. Then, supporting such schema would require us to put more checks everywhere in the code. So overall, not mixing up @remote with non-remote kept things simple for us.
If you want a remote type to implement an interface, declare a remote interface.