I hope I am not misrepresenting others, but my understanding is that this is the root of the disagreement: Mike would like a relatively tight specification of the project and its goals. If I understand @mans_magnusson and others correctly, they consider such tight specification premature and not necessarily useful/desirable. I am also not sure the discussion brought us any closer to agreement on this point (while I fell agreement on other aspects has mostly been reached). If this is a correct assesment, I think moving to a vote might be the best course of action, possibly with voting on three options (exact formulation pending) “Include as is”, “Include if tighter specification is given”, “Do not include” - and require an option to get overall majority to pass (with possible second round with two options is this does not happen).
I would also personally like to resist a bit the call to define a “General process for including projects in Stan”, I think there is a huge variation in motivations to include a project that warrants a case-by-case approach and I don’t think inlcuding a new project is something we would do often enough to justify a rigid process - or to let us debug the process in place.
I think the idea to have some midle ground of “Stan endorsed” or “Stan affiliated” projects that are not necessarily core is interesting, but I am not sure if it adds anything beyond the current state - most of the projects that would fall into this category are routinely discussed on the forums, linked from the Stan website etc. so I think they are de facto endorsed already and I am not sure this additional structure would be so useful.