The following was a reply in an e-mail thread. I've since cleaned it up and added links to background information. I haven't heard back since I sent it.

If any part of my response seems redundant or disjoint or otherwise unnatural, it is because I did not sit down in one sitting and write this all. Instead, I jumped back and forth between points, hoping at each step that I had answered the subquestion adequately.

I want to use Transit as my OS, and I want everyone else to want to as well. I want Transit to be as pure as possible. Before I can use it, someone has to write it. I want to be the one to write it. I want time to write it. Two strategies I can think of for making time to write Transit are:
I would prefer the latter. I think implementing Transit as an academic research project is a way to get paid to write it. I don't want my work, my research, and my attempt to implement Transit to be three separate parts of my life, all competing for time and effort. I want to integrate the three into one project that I can devote the majority of my waking hours to. That is the selfish truth about my motivation. I want this tool, I think I can write it if given the time to do so, and I want the time to write it.

Now, as for the technical motivations for why I want to have this (and thus why I want to write it), here are a few reasons:

First, I'd like to formalize the system and create a reference implementation. In doing so, I hope to open some questions that can create further research opportunities for myself and others.
After getting a slow, theoretical version working, I will want to optimize it for different kinds of efficiency.

In the immediate future, I want to formalize this new paradigm, create a reference implementation, and learn about its consequences. I have a vague idea of the kinds of applications that will be well suited to this paradigm, but I think I'll have an even better understanding once I actually implement the tools.
Some of the questions I want to answer in writing the tools include:
In the long-term, one problem that would require Transit or something like it is a concept I like to refer to as the over-butler. As people integrate computers more and more into their lives, it becomes more and more beneficial to them for their computer to be intimately familiar with them. However, as people move more and more of their personal information onto machines they don't control, such as Google's servers, privacy issues become more relevant, especially in light of this increasing human-computer intimacy. If the same computer that helped me schedule my appointments also knew how to accurately predict when I would be hungry, it would require less manual intervention and cognitive burden on my part to tell it the things it needs to know to help me predict where I'll need to be at what time. This would be like the goal of a learning Personal Digital Assistant. But these days, people use computer networks to coordinate with one another, and a single secretary-like computer would be almost useless if it can't coordinate with others. However, a user concerned with privacy would want such an intimately-familiar butler-like agent to not disclose certain information to the public, and there are likely few other machines with which the user would be comfortable trusting well enough to share everything the learning PDA would know. In the same way that the agent would learn what the user's wants and needs are, the agent should learn how to predict who the user trusts and how much the user trusts them. Armed with this knowledge, multiple butlers can negotiate to orchestrate economic transactions, social interactions, and other kinds of compromises. To do so, however, would require a trust network so sophisticated that it would require an underlying platform like Transit to work. I hope to some day let my computer worry about when and how I'll go places and do things, so I can focus on enjoying the things it tells me to do, without getting bogged down with the minutiae of how and why to do them. I don't have the expertise to implement a single butler, but if I write Transit, someone else who does could write an overbutler application for it.

I want to solve these immediate problems so I can have a better computing environment to work with. I want such an environment so that ideas as grand as the overbutler suddenly become feasible for an individual to imagine, design, and implement. I can't imagine what kind of system someone else will build on top of Transit, but I want to give them the ability to do so.

The data structure attempts to be minimal for flexible, semantic representations of everything anyone would want to store in a computer.
I've convinced myself of its completeness by the following argument:
Anything I would want to tell a computer must have a finite, symbolic representation.
Any finite data structure of a fixed type must be able to be expressed as a relation.
Any finite relation can be expressed as a finite table or spreadsheet-like view.
Any cell of a spreadsheet can be uniquely identified by its row, its column, and its value. There exists a functional dependency between (row, column) and value. Thus a set of cells is a relation with the schema (row, column, value) with the key (row, column).
If I have finitely many rows, columns, and values, I can take the union of those sets and number it with a compact subset of the natural numbers.
Thus each relation can be pivoted into a relation of triples of natural numbers.
So up to numbering, we can take the union of all of finitely many schemata, pack all of our data into one large relation with many null cells, and represent the non-null cells in a relation of triples. We can extend the schema at any time by adding a new column, and we can create a new object by adding a new row. Because we only sparsely store the non-null cells, there is not the huge cost of adding a row or column full of nulls.
In this way, I am convinced that anything I want to tell to a computer, I can express as triples of natural numbers, as long as the computer understands enough semantics on enough of the numbers for me to explain what I mean by each number in terms of other triples in the same structure.

I want the transmission of triples to be the strongest requirement on homogeneity (the second strongest being the a priori agreement about the structure of the graph to do computation) so that implementations are free to take advantage of features on the other side of the network interface. For instance, if this protocol is used for a project like Folding@home, a compute node could run a specialized peer that takes advantage of local hardware to perform the computation, but the results could be transmitted over triples. This way, the compute node doesn't have to do all of its work in the graph, but the fact that it doesn't do so is invisible to the other peers, who only think that the compute node isn't sharing its intermediate results.

The paradigm I want to create can be described as "conflict-tolerant" (or, as I prefer to call it, "controversial") distributed computing. The purpose of conflict tolerance is to allow collaborative agents to achieve more than they could if they were intolerant of conflict. In a conflict-intolerant system, either messages get dropped if they don't satisfy the assumptions of the recipient, or the sender gets blacklisted. I feel like this is a case of throwing the baby out with the bathwater. The recipient should not naively accept everything the sender says, but stubbornly refusing to ever believe that sender again wastes potential. What if the sender is only unreliable in one area? What if the recipient was wrong and unjustly disbelieves everything from that sender from then on? What good information is lost by such an inflexible policy?
Controversy is just one aspect of this paradigm, though. I also chose the data structure and network protocol to facilitate introspection and knowledge representation. Any nuanced definition of trust will depend heavily upon the ability of agents to justify themselves to one another, and the first step to that is to increase their awareness of why they believe as they do. Universalization of data also allows applications to interoperate better. I am often frustrated by the fact that my web browser doesn't use FUSE to mount the Document Object in the filesystem. If it did, other applications could manipulate the DOM of an open web page. Interoperability is at the core of both conflict-tolerance and semantics. The buzzword I hear people use these days for such interop is "mashup".

As a distributed system, Transit cannot afford to naively assume that every agent is operated by a benevolent user. Even if it were, however, people make mistakes. I want to see a computer system that gracefully retrieves meaningful data from even malformed interactions, perhaps well enough to proceed as if there were no error. No single agent should be able to deny service to all others just by creating error conditions, but every agent that has anything meaningful to say should be able to contribute to the solution of whatever problem the agents are trying to collaborate to solve. A blackboard system could self-assemble if the expert agents are aware of each others' areas of expertise and use that knowledge to determine when to trust one another's claims. By analogy, a historian and an archaeologist can work together with what they both know about the overlap of their fields, but they must know how much to trust one another about the disjoint subsets of the union of their knowledge, and a third-party anthropologist must know which one to trust when listening to the two talk about the same thing, especially if they disagree on some point. In the same way, allowing the computer agents to specialize based upon what they know necessitates discernment of authority. In a decentralized system, determining authority requires some sort of trust policy I've never imagined. I would like to learn about these policies in general by building and using the tools that bring about their need. Humans resolve conflict not by blacklisting anyone who has ever been wrong, because we cannot afford to get through life if we are that unforgiving. I want to see how much more machines can accomplish if they develop definitions of trust that are as nuanced as ours.

UI and OS
Because I want this Transit project to be able to do everything I want to do on a computer, I want it to be possible to do away with everything else. This means I'll need to be comfortable interacting with Transit alone, without the aid of Linux's kernel or X11's graphics subsystem, unless they themselves are ported to run on Transit. I want to explore the kinds of interface that make sense to use with the constraints and possibilities of Transit. What metaphors will make sense when the OS is distributed and controversial? How would a user prefer to interact with the graph in general and with particular applications that run in the graph? I would like to see if the tools necessary for establishing trust also apply to learning how best to present information to the user. I'm also interested in Zooming User Interfaces and Microsoft's acquired Seadragon. I would like to build a ZUI on top of Transit some day, but I can't do so until I understand Transit and how to program in it.