In all these cases that you mention, @Astn, an edge in that direction would need to be present.
In Twitter, when you follow someone, essentially 2 edges need to be created: ME --follows--> YOU, and YOU --followed-by--> ME. We don’t assume or try to create the reverse edge. In my experience with graphs, a blind reverse edge generation can lead to many scalability problems. For e.g., you want to tag every person as a person. ME --type--> PERSON. If we generate a reverse edge for every such instance, it would blow up the number of things attached to PERSON, and won’t be very useful.
We could, though, have helper functions around this, where you can specify which predicates need to have reverse edges, and what should they be called; and we can have some automation around that. But, as a design choice, our edges are unidirectional.
Again, this is a lot easier to solve when you store the data as such. For e.g., with web pages, if you encounter a new page, store the outgoing link as from page → to; and as to -incominglink-> from.
Having said this, if there is demand for such a feature, we could have an option; but it would need to be turned on, with the understanding that the disk usage would be doubled at least, and could blow up some of your indices; like the person example I mentioned, where one vertex could point to theoretically 7 billion other vertices.