Not "want", I appreciate the positive properties, but the fact that even I am still running into walls and more special cases would need to be added, plus the other mentioned issues, could just be a sign that this restriction may just not be a good idea after all. I hope that you can wake up one day and suddenly you realize how these restrictions have just restrained your life up to that point ;)

:-) I can be quite stubborn, but I always try to understand the other side and I am very grateful that you took the time to explain your view of things to me and especially that you considered the proposal. I like clean concepts a lot, but obviously the D package = package assumption was too neat to be reality.

Well, in your case you also have to make sure that all packages adhere to the restrictions, you have to manage those :suffixes, implement all the new concepts like sub-packages first and whatnot. Just adding a list of D packages for each package record really is trivial and has the nice property that it can be done at a later point when needed for the scripting feature or when it shows that people create unwanted conflicts.

It is more work and less straight forward, but with a good infrastructure and the right tools it would not be too bad. I guess this is what computers are there for.

I totally disagree. This is far less work and much more straight forward. Try to list up all the things that are necessary to implement for your proposal. If you are careful, you'll see that there is actually a lot of work in it.

If you consider proper handling of circular dependencies and stuff, for packages that don't fit the scheme. Likely! This also was, what finally convinced me to drop it. I have to admit, that I am already in a position, that if you changed your mind now and say let's do it, I would say: "Are you sure? I think it is garbage."

It is simple, the core concept, it's fitting things into a model that they weren't made for that makes things complex.

I totally agree with that, as I already said, if the basic assumption of the proposal is not matched in reality, it is not worth the trouble.

Well, depending on the use case that may be the case, or may be not (you can only consider actual module clashes as a conflict, or you can already count package clashes as conflicts). Anyway, I fail to see the problem, even when capturing all modules.

Counting package clashes as conflicts does not work. Think of "org.eclipse.swt", most certainly another package should be allowed to use the "org" package or "org.eclipse" or even "org.eclipse.swt.something.not.in.the.base.dwt.package". Not even restricting the check to leaf packages (packages containing only modules) would be ok in all cases, if we think of C libraries that are made available via a single D module. But I agree, having to capture all modules is no real problem.

I have to think a bit more about the consequences of not implementing my proposal, but with the right infrastructure and tools available, most issues should be solvable. E.g. having an IDE showing me the containing package name when I hover over an import line, having a commit hook that calls dub with some parameter that checks for conflicts with the registry, ...

Sorry, but that's a totally unrealistic case you make up there. Please, show me where such conflicts happen in reality and we can talk about it, but constructing cases like this is just... after all we have concrete issues with the restricted case but still not one concrete example of issues with the unrestricted case (and there is a sheer unlimited set of examples in the world).

I don't exactly know what you are referring to? To the commit hook thing? I am just saying that one can set up something like that, if he wants to be on the safe side. But never mind, it is quite possible that I am taking this conflict stuff a bit to serious. If you refer to the first sentence about consequences, I was not thinking about conflicts in this case, but rather whether my original goals for a package manager can still be met. "Consequences" might have been a bit of a too hard word, what I wanted to say was: "I have to think everything through again on top of the changed semantics".

I hear you, I used to see that clean package tree right before my eyes :)

...but then reality came in and destroyed everything ;)

I am happy that I am not alone with this! ;)

Best regards,

Robert