[DISCUSSION] Revisit package naming to better reflect the DI-first integration model

[askpt]

Requirements

If DI and Hosting are split, the current package names may no longer reflect the hierarchy clearly. Discuss whether renaming to something like OpenFeature.Core (base) and OpenFeature (DI) would make the model more intuitive for modern .NET consumers.

[arttonoyan]

I think this is important because package names should reflect package responsibilities as clearly as possible.

If DI and Hosting are split again, naming becomes more than just a cosmetic question. At that point we would likely have three different roles in the package model: the core SDK, the main DI integration layer, and higher-level hosting-specific extensions. Clear naming would make that structure easier to understand for consumers and easier to extend over time.

I also think this matters for future package consistency. If we keep the current top-level names and reintroduce OpenFeature.DependencyInjection, some follow-up package names may start to feel awkward, especially around provider- or hook-specific DI integrations. For example, names like OpenFeature.DependencyInjection.Provider or OpenFeature.Providers.DependencyInjection are possible, but they do not feel very natural and make the hierarchy harder to reason about.

For me, that is the main reason to discuss renaming together with package boundaries. It is not only about making the current packages look nicer. It is about keeping the package model intuitive, consistent, and easier to grow as new integrations and extension packages are added.