There’s quite a few good questions and remarks here, I’ll be writing another long post now 
Yes, they are. They could be decoupled cleanly later on if needed, but I doubt we’ll ever reach that level of complexity. Especially given that the tooling available in .NET is quite advanced when it comes to this (as opposed to C) - we don’t need to write up our own HTTP protocol transport, it’s already there!
Naming wise it’s what I thought it would work at the abstraction level that Speckle operates 
And ultimately, since the ITransport interface doesn’t enforce the actual transport protocol one would be using - you’re free to use SSH or whatever fits. E.g, the server transport currently uses http, the sqlite one uses the sqlite driver, the disk transport uses system files, etc.
What in git terminology would be References - namely Streams, Commits, Branches, etc. is a different abstraction layer in Speckle 2.0. Transports deal exclusively with storing and retrieving objects (our tree-blob hybrids).
These sit alongside the Transport layer. To give a short example: once you have an object id (hash)* from a ServerTransport, one can “bless” it as a Commit in a given Branch under a specified Stream on that specific Server.
We haven’t abstracted References under their own interface (yet?) as right now only the Server can handle this, but this might be a good idea. Doing this might actually simplify some future connector work. Anyway, I digress…
Notifications are bound to References, and objects. If you build up a reference layer on top of, for example, sqlite, you could use polling (unless there are db update events in sqlite). Or, if we get around this issue, they’ll be available in .NET on the Speckle Server client!
*My policy is to always talk about object ids as ids, but for the next six months or so, emphasize that they’re actually a hash 