thank you David.
my assumption was that a repetitive X type of flow was implemented as a stream of X rather than by passing a single "list of X" object when the list was completely compiled. i assumed that because passing complete lists does not scale to large numbers of items.
in fact, i even thought that an "end of stream" token was not implemented and that that is the reason why empty lists don't seem to flow and tersus needs a special "erase" (or whatever you call it) type of flow.
however, that is not the case.
i have zero modeling experience (with tersus or otherwise) but i have some preliminary intuitions nonetheless. it's probably too late to change tersus, but IMHO...
1) given that you are passing complete lists, i don't see why empty lists should be a problem. a hack such as the "not found" exit in database find should not be needed to clear lists. and the receipt of a list should not append to a repetitive datatype, it should overwrite it. this would probably make the "erase flow" totally unnecessary. (if appending is still needed in some special scenarios, an "append flow" could be defined. but to define append, careful examination of the problem of the resulting ordering is needed.)
the rationale is that the need for special handling (like the "not found" exit) should be eliminated so that models behave correctly under special circumstances by default, without the modeler having to do any extra work.
a model instantiated as repetitive should exit one list out of every normal exit (possibly an empty list).
2) the automatic conversion from list of X to X should be removed form tersus. i can find no rationale for the current behavior, picking the last element of the list; it seems to be useless. for the case discussed above, adding a simple <done> exit to the repetitive submodel would provide the signal needed to finalize the process (closing the window, etc). otherwise, a simple "count" template could do.
the rationale is that this way the model would be better checked for correctness at compile time. forgetting to declare a submodel as repetitive would trigger an error rather than compiling a silently misbehaving application.
also needed would be a template that expects a list of exactly one X and outputs this X (for cases such as find by primary key). its use would improve models in two ways: by explicitly documenting the designer's goal, and by checking the single-item-list assumption at runtime and raising an exception if the assumption is violated.
3) flowing a nonrep exit to a rep trigger, implicitly "replicating" the flowed data, is probably ok. but other more explicit solutions should be investigated. explicit solutions have the benefit of catching more errors at compile time.
4) tersus semantics should try to accommodate a possible future implementation of repeats using streams for scalability reasons. if done correctly, such a change should not break existing models.
For best results, use the Firefox browser..