This is an excellent question. First my own remarks on programming in the wolfram language. First I have a general idea on what to create. (the algorithm is my invention and the computer only executes it)

I create a few snippets of code for the crucial areas to check how complicated or easy the problem is (storyboard coding). Then I create a flowchart of input and output-data-formats and function names. This exercise creates more insight in the problem and in most of the times it simplifies the solution approach. (do I need global data objects or will I go for the non global symbols approach)

Then I create two notebooks. One to program the functions and one to test the functions. After programming the next function in the flowchart I test the function in the testnotebook (the programming notebook can be kept clean by doing all experiments in the testnotebook). When a few new functions have been added and tested it is time for an integration test by running the full testnotebook. So before I look at the Workbench all programming is done in 2 notebooks.

Every set of functions in my flowcharts are subdivided into more aggregated blocks of code. The idea is to put every aggregated block of code into a subpackage and then merge it all together into 1 Main[] function. So subpackages need to roll-up into 1 main package and my global variables need to be global to only the mainpackage context. Let's load subpackage P1 and P2 and the globalvars package.

BeginPackage["Main"] main::usage = "main[]..." Needs["Globalvars"] Needs["P1"] Needs["P2"] Begin["Private"] main := .... End[] EndPackage

The most important thing is not to include P1 and P2 in the second argument of BeginPackage. The reason is that they are Needs that are executed before the BeginPackage command itself. This puts P1 and P2 on the contextpath before Main is added. The problem arises when EndPackage is executed. This switches back to the contextpath status before Beginpackage. So P1 and P2 stay on the contextpath when leaving the package. The way Needs is used here is called Hidden import.

Now there is a new trick in M10. Usage exports a function from the private to the package context. But this now also works of a package in a package in a package. Every usage function is now visible to only the 1 level higher package. With this approach all your symbols are recognized in all your packages and you never have to use full context to refer to something. So you end up with only 1 context added to the ContextPath when you arrive back in the global context. You global symbols are now global to the context Main and lower so there is not issue if the use accidentally creates the same names in Global` context.

This is the moment when I start to use the workbench. I import my programming and testing notebooks and create .wl files for the package structure I need. This structure by the way depends very much on the number of programmers involved. Every programmer gets a part of the overall function flowchart. He/She then subdivides his module in files using Get as a stub to a placeholder section. The workbench has support for GIT and via GIThub you get version management control on the whole team. When you start to do some builds it is good to now you have all documents, notebooks, packages etc. in one place. In some occasions programmers de-rail into developing a solution and feel the needs to switch a few versions of their files back. This is easy when the package files are organized by programmer.

The new nested packages approach is a great addition to developing large programs in the Wolfram language since you organize by programmer and by aggregated package and execute version management on each of these files.

David, I have investigated your "Context Problem example". One of the issues (I think) is the use of Needs in the BeginPackage statement. Let me know what you think about my reply to George?

Yes, do some simple experiments to see if you have the general idea scoped out and let me know if you get to a point of confusion or contradiction...

One question that I'd ask first is why you want to do this. One reason may simply be organizational--that you want to create several different packages and have the code-base for each separate. An immediate question arises as to whether there are dependencies amongst the packages. Of course if there are dependencies they must be in a descending tree structure: no closed loops. Another question is whether you want all of the packages to be loaded at the same time. In the "old days" sometimes people wanted control over which packages in a group were loaded so as to conserve memory resources--that's rarely necessary these days though, unless a given package loads significant data resources, insanely large expressions, or needs to do some time -consuming calculations in the course of its loading.

I tend just to put everything into one package... and I generally program in a notebook rather than Workbench. But this is a matter of preference of course--there are advantages to each approach. If programming in a notebook, I just put the code for distinct areas in different section organizations. The size of the code is immaterial (subject to the caveats above): I have packages with on the order of 60k lines of code and they load quickly.

As for your question--there are several approaches. One general approach is to have a top-level context and to put all the subsidiary packages in their own contexts. Then in the BeginPackage call for the top level package, also include the other packages in the BeginPackage's second argument. Or the packages that are included in the BeginPackage's 2nd argument may not be all of the other packages' contexts--the contexts in that BeginPackage command as well as the other packages' BeginPackage commands can reflect the package dependency. Also the advantage of using BeginPackage for each sub package is that each will have a private sub-context and so one can have the public symbols properly separated from thePrivate stuff in each package's sub-context.

Another possibility that one may think of is to code the subsidiary packages' code in a way that does not declare contexts and just pull them in using Get inside of the main package's code as needed. This presents a problem since this either has to be done before the Private sub context or before it. Then it is a mess to get the subsidiary packages' public andPrivate symbols placed correctly: explicit full context names would need to be used. So this is a non-starter I think.

So, those are some thoughts...