No the problem has not changed
Perhaps those who read the word 'project' immediately thought (this is because usually the Access developers work on a single file) to a single Access file
But already from post9 it was expressly indicated that a 'project' is to be understood as composed of one or more Access files
"..I asked how to organize a project (also understood as a set of multiple Access files.."
I SPECIFICALLY addressed the "multiple section, larger dimension" issues. If this is not enough, then I repeat that YOU DO NOT APPRECIATE what you are actually asking. I'm trying to be polite, but your continued rejection of what we all have been telling you makes me think that this is becoming an exercise in mental auto-eroticism. (Can't use the exactly correct "M" word here for multiple reasons including censorship and the fact that such a word would negatively affect the forum's online scores.)
And YES the scope has changed as your original request, as clarified in your post #5, asked about exceeding limits by one object.
The question is: how to organize a project to avoid it reaching dimensions incompatible with the limits of the development environment
All other considerations are useless
The "development environment" for an Access project IS the single file MSACCESS.EXE, which works on one object at a time, so there is an implication of a single object there. You later clarified a little bit, but still left something totally open-ended.
I asked how to organize a project (where by 'project' I do NOT mean a single file) so that it can support a growth that cannot be defined from the start
OK, I'll answer it this way. No disrespect intended, but to even accept consideration of a project with undefinable growth limits is insane. No decent manager would ever accept such a project. If I owned a company and some idiot employee calling himself a manager accepted such a project while working for me, that person would no longer be working for me AND would be personally on the hook for liability issues originating from or related to having exceeding business authority. The relevant problem is, in the real world, that a project's internal connectivity issues grow either exponentially or factorially vs. the growth of the number of elements, and NEITHER growth style has a shallow slope.
I watched a U.S. Navy project called "DIMHRS" go belly-up, not because it couldn't be designed at a high level, but because it had so many interactions that nobody could agree on how to do the detailed conversions for interactions between any two branches of the U.S. military that, years ago, had each developed their own system. Which they did because there WERE no easy ways to interconnect systems in the 1950s and 1960s. This little project didn't even have the "infinite growth" problem and $10 Billion (U.S. dollars) was not enough. That amount was where Congress "pulled the plug" but I can tell you it would have continued to grow seemingly without limit.
This description ("growth cannot be defined") is EFFECTIVELY an infinite project which will require infinite resources. Don't you SEE that? If you CANNOT place a limit on it, I guarantee in writing that it won't get done to everyone's satisfaction - potentially, to ANYONE'S satisfaction. But you later gave us THIS question.
how to create/organize a project whose size in terms of number of objects (form/report/code) goes beyond the maximum limit possible with Access
When dealing with Access limits, my previous discussion on "divide and conquer" (into separate and distinct targeted apps) means that you HAVE no Access limits as long as you can still subdivide the problem. All the remaining limits are then imposed by the capacity of your machine including CPU capacity, memory size, disk capacity, network capacity, and internal bus limitations. So buy another few machines and keep growing the pieces-parts. Without specifics, I believe that no other answers are possible. And if you cannot further subdivide, you are stopped by a limit that nobody will be able to surpass.
