I really hate my conclusions here, but from a limited freedom point of view, if all of that is going to happen...

> The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec

So we should better start with a standard scaffolding for the replies so we can encode the errors and forget about status codes. So the only thing generating an error status is unhandled exception mapped to 500. That's the one design that survives people disagreeing.

> There's a decent chance listing endpoints were changed to POST to support complex filters

So we'd better just standardize that lists support both GET and POST from the beginning. While you are there, also accept queries on both the url and body parameters.