Even after overcoming the problem that Mk4tcl needs documentation, one discovers that the available commands don't form a complete set.
Most notably, there is no subcommand of a view instance command that has the power to define a subview property in any view. This means that the one and only way to define a subview using Mk4tcl is via the [mk::view layout] command, which requires a path argument. Thus, one cannot define subviews in views that have no path. This is a severe limitation.
The command [view view groupby] almost provides at least a limited way to define subviews, but it requires that a property of type subview already exists. It can completely redefine the structure of an existing subview, but cannot create one.
If [view view groupby] were a true inverse of [view view flatten], then there would at least be an awkward way.
Other approaches might be removing limitations on [view insert] that allow it to auto-define only non-view properties, or the addition of a [view layout] command, or the extension of [view info] to accept arguments for redefining the view structure.
If someone passes me a view there is no way for me to determine its path.
In particular, I cannot determine what dataset view belongs to, so I cannot commit any write I make to view unless the caller also passes in the dataset name.
There should be view subcommands for these operations.
JCW 28-8-2002 - The "cannot introspect subview path given a view" is a limitation of views in MK today, and is quite a fundamental issue, unfortunately. At a certain level, MK views have no info about their parent. In fact, the original allowed referring to a view from multiple parents (the infamous attached vs. unattached view issue).
As for the other rough edges: part of this is caused by a Tcl binding which was trying to be too clever and which by consequence makes it hard to get things right. The Tcl wrapper is much larger than the Python one (and predates it).
Getting this right may require re-doing a meaner and leaner Mk4tcl successor. But the trouble is that if that is the choice, then I'd much rather work from a meaner-and-leaner MK core (in C, not C++). With truly minimal wrappers for various languages. This is the "M2K" (pipe) dream I have been contemplating for ages...
The good news is that while the MK code is perhaps showing its age (6 years), the 2.3/2.4 data structures are very well suited for the task they have to solve, and have lots of leeway for future extensions. So this is a matter of re-coding, it need not affect existing datasets.
Script to dump a datafile as Tcl script which reconstructs it