remove redundant namespaces

[SimonCropp]

There is no value in making the internal directory structure be reflected in the public API namespaces. it actually adds more noise since it often request consumers to add more using in file headers. it obscures apis from intellisense for no value.

[ghost]

Thanks SimonCropp for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[michael-hawker]

Thanks @SimonCropp for submitting another PR. I know there was some discussion on this topic on Twitter here. It didn't seem like there was a concrete outcome of that discussion?

It could've been good to start this as an issue discussion here instead of a direct PR first.

I know the original intent here was to map to the BCL for the underlying interfaces.

I'd love some more input from some of the folks who've been helping us review this work on this namespace topic and have already been using the library in testing things out.

@mrlacey @tannergooding @deanchalk @jamesmcroft @sonnemaf thoughts?

[mrlacey]

I think this comes down to preference.
Some people like more, specific namespaces and some like a single higher-level one.

offer an "à la carte" solution with building blocks to freely pick and choose. Using namespaces helps separate the various modules better.

I'm not convinced that having multiple namespaces makes it easier to use individual pieces.
In the above quote (source) it's not clear what "better" means. Again, I think this comes down to preference.

As there is nothing that requires multiple namespaces for disambiguation, and as the contents of each namespace is small, my preference is towards having a single namespace.

While tooling does make it easy to add multiple namespaces when needed, putting everything in one namespace avoids making this an issue.

A quick review of the existing codebase shows inconsistency in this area. (I was hoping for a precedent. 🤷‍♂️)
Whatever the outcome here, a follow-up task needs to be created to look at applying standardization. Or at least define rules for future additions to the toolkit.

[michael-hawker]

Thanks @mrlacey for insight here. In terms of precedent, I agree that we should have better guidance for the Toolkit as a whole here. We've grown very organically over time, so we need to catch-up on managing a larger project. That is part of our goals with the 7.0 feature planning here though currently more from a package/dependency stand-point.

If you noticed other examples in your quick search, would you mind calling them out in a new issue? 7.0 would be the time to clean things up across the toolkit, so I can link it in our planning memo.

[SimonCropp]

While tooling does make it easy to add multiple namespaces when needed, putting everything in one namespace avoids making this an issue.

"putting everything in one namespace" also minimizes the noise in the C# usings header block