It appears that it wanted to be services.WeatherService, which if reduced to service.Weather isn't looking so bad, but core ended up being introduced because the unnecessary interface already overloaded the namespace. The code doesn't accidentally highlight - it is crying out.

> always makes me feel like my types are dangling out in space

That's the idea, though, isn't it? Each package is its own distinct thing, intended to be useful and usable across many projects. There shouldn't be any kind of deep interconnectedness in most cases – and where there needs to be, you will typically place the related packages in a subfolder to communicate that relationship. I can't think offhand of any package manager that maintains anything other than a flat list of dependencies, and that's essentially what you are building here too.

I do think you have a point that many other ecosystems have a mindset where you are only building a single application with no attempt to find reusability beyond the immediate codebase. In large part because those languages/ecosystems require a bunch of extra, often complex, steps to make packages exportable. It can be a bit of mental shift to consider an application as a set of discrete, reusable parts if you come from those places.

Example: WeatherConfig, WeatherService, WeatherPollInterval => weather.*

It's exactly what I was looking for

You could have it respond with JSON, but then the rendering of the weather widget would have to be defined by the consumer instead of the tool server -- now the 'chat' part of your system needs to be aware of all possible content types, how to detect and render them; it's also doable but a different set of trade-offs.