This was discussed before: Combining export and extension - #14 by sageserpent-open and in more detail here: Supporting import in extension method blocks - #38 by Russ - Language Design - Scala Contributors.
Is it really the case that your classes can’t be broken down into separate classes? How many methods are we talking about here? Are these mostly public API methods, or are the majority really just implementation detail?
Split them up into separate abstractions at different levels, or if you must have a giant class, use the composition-and-export trick that was mentioned on the first linked discussion.
Unless you can solicit buy-in from the compiler team (or you submit a PR to them), either way is going to be quicker than getting a language change made for what seems to be a very one-off use case.
A different take on this is found in this core class that is extended here.
CodeMotionAnalysis defines a single almighty factory method in its companion object, and that breaks down internally into a localised universe of classes and functions. It’s big alright, but there is a decomposition into multiple levels. Very 1970s Pascal-style, but with an IDE it’s straightforward to navigate.
The extension adds the ability to work with the analysis to perform merges: it could have been written as a completely separate abstraction, but I felt that the code spends all its time dealing with a CodeMotionAnalysis, albeit only via the public API, so why not make it an extension?
It is another big blob of code, so folding into the core class would have stretched the size even further. As there was a natural fault line between the two, the extension approach seemed natural.
As there is one factory method in the core class and one in the extension, and both are large, the overhead of the extra access syntax isn’t a bother.