Even though you do really have a point that the current GtkTreeModel interface is way too complex, I am getting very, very tired about the way you are trying to get this across. We have discussed your ideas in person some time ago already and I am very well aware of the direction in which you want to head.
You are comparing GtkTreeModel and DataTable in .NET and saying that GtkTreeModel is not generic like IList is. That is a correct observation, because GtkTreeModel was not at all designed to be a generic model. Note it was named GtkTreeModel, not GModel, GtkGenericModel or whatever. It was designed to be a model for GtkTreeView and nothing else. And yes, it is being misused.
So why was GtkTreeView not designed like that? Well, you give the answer to that yourself in your earlier blog entry: we did not have a collection framework.
Doing it right, like .NET does, requires a collection framework. You are talking about IList and IList is a part of .NET’s collection framework. I am not at all opposed to walk this route and introduce proper models in GTK+ and GtkTreeView can then also use these. But it is not at all fair to keep comparing .NET’s generic data binding with the current non-generic GtkTreeModel.
For some reason you feel obliged to mention that the .NET implementation will only access data of visible entries. You know that for GtkTreeView the same holds if you are using fixed height mode. And you also know that I have been working on patches that will remove the validation process that has to iterate over the entire model in advance, making it possible to work with very large models without using fixed height mode. In fact, this will deprecate fixed height mode.
It is easy to pick on work people have been maintaining in their spare time, but it does not provide a form of motivation nor encouragement.