Keyword "package" prevents from importing a package module "package.d"

[Andrey Zherikov]

On Thursday, 2 November 2023 at 19:43:01 UTC, Adam D Ruppe wrote:
> On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis 
> wrote:
>> The entire reason that it was added to the language was to be 
>> able to split up existing modules without breaking code. And 
>> it does that well.
>
> No, it doesn't do that well at all. In fact, it does that so 
> extremely poorly that (as you might recall) there were a very 
> large number of support requests shortly after Phobos started 
> using it about broken builds, since it would keep the old file 
> and the new file when you updated and this stupid, idiotic 
> design can't handle that situation.
>
> This only subsided because enough time has passed that nobody 
> tries using it to break up existing modules anymore.
>
> It is just a *terrible* design that never should have passed 
> review. It is randomly inconsistent with the rest of the 
> language and this manifests as several bugs.
>
> (including but not limited to:
>
> https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work 
> with .di
> https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you 
> try to use it for its intended purpose
> https://issues.dlang.org/show_bug.cgi?id=20563 error messages 
> hit random problems
> <can't find the link> all-at-once vs separate compilation of 
> package leads to inconsistent reflection results
>
> im sure the list went on if i spent a few more minutes looking 
> for my archives)
>
>
>> package.d is indeed completely unnecessary for creating a 
>> module that publicly imports other modules in order to be able 
>> to import a single module and get several modules.
>
> Yeah, it is a terrible feature that is poorly designed, hackily 
> implemented, and serves no legitimate use case.

Is there any guide how one can refactor single-module package 
into multi-module package with distinction between public and 
private modules?