JDRiverRun

You have the wrong target. I don't think you are (or should be) actually complaining about use-package, but about the setup of various cross-package "tie-in features". So magit knows about project.el. It kindly offers to add a special command to project-switch-commands, but (quite reasonably) only after project.el is loaded, and if project-prefix-map is defined. Luckily the latter is a builtin autoload, so it's just a matter of ensuring project is required with magit before you can use the tie-in, whenever you want that to happen.

As already pointed out, you could add (require 'project) directly in magit's use-package :config stanza to make this tie-in happen right away after magit loads. Or, perhaps even better, identify a hook (magit has many) to do this "just in time" before you use magit in some meaningful way. If you want this tie-in to happen somehow magically without loading magit, good luck with that; it's a literal top-level (with-eval-after-load 'project) in magit-extras.el! You only option is therefore to do what you did: boost that logic out into your config. Or how about this: (require 'magit-extras) in your (use-package project :config). That way you're only loading a tiny part of magit when project.el is loaded.

The bottom line: how is use-package or any other config paradigm supposed to know when you'd like magit's project.el tie-in to activate? Some people would like to have project -> magit interaction on demand the very first time they invoke the project menu in a git-controlled file. Others want that tie-in command available only if they have already been working with magit in a session. You apparently want it active and ready to go without loading either package. This is way beyond use-package's scope. The only solution is to investigate the nature of the tie-in, and configure it yourself to work the way you want. Which is what you did ;).

Can you comment on what the future for this JSON-handling-in-a-separate-thread emacs fork looks like, currently? Any hope of upstreaming some perhaps more general version of limited multi-threaded support of this kind? Other "downstream" forks (like emacs-mac) miss the benefits.

A variable watcher maybe.

    (add-variable-watcher
     'myvar
     (lambda (sym val op buf)
       (when (eq op 'set)
         (push val (get sym 'prior-values)))))

Try emacs-mac, works great there.

Did you either succeed with debugpy.listen()? Is that suitable to call interactively then quit (like iPDB)?

M-x find-library python, followed by C-s outline- shows what's happening: python-base-mode sets the local outline variables locally, in its mode body. Since mode hooks always run after the body of their mode definitions, you could add a bit of code to the python-base-mode-hook (or a parent of it, like prog-mode-hook) setting your desired outline config there (i.e. overwriting what python mode did).

I do that using outli simply (in a use-package stanza):

 :hook ((prog-mode text-mode) . outli-mode))

BTW, here's a handy guide (from this epic answer) to what runs in which order upon invoking a derived major mode like python-ts-mode:

So when we call (child-mode), the full sequence is:

(run-hooks 'change-major-mode-hook) ;; actually the first thing done by
(kill-all-local-variables)          ;; <-- this function
,@grandparent-body
,@parent-body
,@child-body
(run-hooks 'change-major-mode-after-body-hook)
(run-hooks 'grandparent-mode-hook)
(run-hooks 'parent-mode-hook)
(run-hooks 'child-mode-hook)
(run-hooks 'after-change-major-mode-hook)

Not sure your definition of easy, but this kind of setup (and much more) is certainly possible: https://www.masteringemacs.org/article/demystifying-emacs-window-manager

Start with the Elisp intro; it’s great. M-x shortdoc buffer gives a nice overview of buffer commands. I love consult-info for general searching of the Elisp (and other) info files. But M-x apropos-function is builtin and useful too.

No need for a package, this is a great chance to learn some elisp. To get you started:

(let ((cur (current-indentation)))
  (push-mark nil t t)
  (while (and (not (eobp)) (= (current-indentation) cur))
    (forward-line 1)))

Seems like in-process debuggers like iPDB are far more practical for interactive debugging of long running shells.

How would you attach a DAP python debugger to a running instance of (i)Python? Is there some import debugpy; debugpy.start() command or similar?

Set a window-configuration-change-hook temporarily, see if the (selected-frame) matches. If so do the split, and remove the hook.