2. There's something like a SocialProblem (TM) where Lispers lack (a) versioning discipline, (b) dependency versioning discipline which exacerbates issues like inadvertent multiple loading, or incompatible loading of libraries. 

 

Semantic versioning won't help you without automatic tools to determine if the API of a library changed in an incompatible way, e.g. if a function removed a keyword arg, or changed the type of an existing arg.

 

 

I would say that semvers should in principle help you detect incompatibilities, but as you hinted with "illusion", maybe these in practice can't be trusted or relied upon generally.  

3. There's actually no issue in principle: inconsistencies need to "just" get fixed by the library vendor/user, or better tooling needs to be used to track your project's direct and transitive dependencies. 

 

It's my personal opinion, as is evident in previous messages, that I think 1 & 2 are issues.

 

You didn't give an example of how exactly those two things are a problem, and how adding those features would solve the problem(s).

 

#1: Assuming that there isn't incompatible passing of data, if A depends on B1 and C depends on B2, and in isolation A-B1 works/passes tests, and C-B2 works/passes tests, then A-B1 and C-B2 loaded together (assuming a non-existent Lisp) should work fine. The problem being addressed is lack of synchrony in the universe of Lisp modules.

 

(My first-order thought is that even incompatible data wouldn't be an issue if those data types are properly encapsulated in classes or structures, by virtue of the fact that those types become distinct by way of different names. I envision that only untyped things could cause problems, like [ap]-lists, strings, etc.)

#2: If there was diligence is properly versioning libraries, and diligence in specifying dependency version requirements, then detection of issues could happen. This is solving recognition of a possible issue.