This is about synergy in a few languages.

(2016)We interrupt this program to note a possible solution for several of these languages here.

I code a really dumb set abstraction in a few languages. In each version one can add an element to a set and query membership. Some versions also allow set union. All these values are immutable. The particular implementation is inefficient—a linked list of elements; we are concerned about efficiency of abstraction here, not efficient set representation. Set union is significant here because it requires bringing two element lists together—synergy.

There is another dichotomy:

I prefer the former for its symmetry. It has no impact on the syntax. I am not aware of any fundamental semantics issues raised by this dichotomy (except that the examples of the latter that I know (such as C++) do not provide creation of new classes at runtime). My OCaml example is of this form.
The module type in OCaml is a class of types that have in common some abstract type called set a value em of that type, and a function from int & set to set, and another function of the same type. The toy module here is called Set and is accessible only thru the filter of the module type Sett. A module type is a compile time notion rather like a Java Interface. It is string enough, I think, to allow for v-tables. That a value of type set is a list of ints is not available at the call sites. This code does not use the features referred to by the “O” of “OCaml”. A more typical synergy app in OCaml. Then see this!
I know of no Scheme except perhaps, Scheme48, that provides efficient synergy. Given either of the two efficient synergy mechanisms that I am aware of (safe & seals) I propose to explore several object styles for Scheme. I do not expect a correlation between synergy mechanism and object styles. There is a problem of invoking procedures from untrusted sources. It may not return or it might return too many times. I am not confident that my code continues to work correctly in the latter case. At least in the former case I do not misbehave. I shall assume for now a function once that takes a procedure and returns another procedure that never returns twice. I leave for another time whether this needs to be primitive.
See this.
Trying to understand this logic
A poor abstraction mechanism
A classic paper by James Morris