I feel that way all the time. One big problem for everyone is just the amount of traffic. But I did read it. I don’t know what else you wanted, which is why I was asking if you needed something else. I still don’t understand from reading this why you want to seperate (A), (B), and ( C) [curse the expansion of (C) into (C)]. I completely agree that more of ( C) would be good or even that we could test Hessians vs. finite diffs of gradients. I still don’t know what you mean by the templating being too hard.
We can test expression identity, but it still seems redudnant to me given the other tests. I do think it’d often be useful to see if a function definition matches a simple reference definition, but that’s different.
What’s really helpful in cases like this that are proposing big changes is to write the spec from the user’s point of view. In this case, that’s the function developer’s point of view. That is, work through an example now and see what’s wrong with the current approach from a user’s perspective and what would be better with the new one.
When discussions get derailed, you may also want to go back and look at what you wrote from a user’s point of view. Keep in mind it’s a lot harder for someone else to understand what you’re getting at than it is for you.
The best thing to do for more controlled feedback is to create a design document in stan-dev/design-docs.