David Martin No worries. There must be some solid reason why we do this that I'm not aware of.
I wanted to just show different point of view.
If we want statistics service to become Analytics at some point it's definitely a good idea.

Metrics as name will suggest users that we will provide some performance summaries.
Statistics may be better name.

Most important elements that may be an issue:

• Dependencies between services and stats are unclear and it will involve additional code to handle those.
• Limited and unclear way to handle api changes, related to indirection of dependencies.
  I'm not sure what are the implementation details for this aproach but it probably will mean a lots of interface based injection which will make versioning and dependency management more challenging.
• No generic way of handling stats outside of the box (but that's probably desired outcome)
• Core will need to have dependency on service (not sure about this one as it may depend how we implement that)
• From my point of view this was one of the main reasons why we suggested core service (networking is not as such challenge)

Despite that there is still some reasonable explanation why we want to have it.
For example if we want to keep this feature optional, legal reasons etc.

I see numerous ways to do it as service, just wanted to point out that that's the hard way of doing it.
We can inject some specific behavior from stats service to core service etc.