Loading built-in package from source

Does anyone know if it's possible to run Emacs 28.2 but load some packages, e.g., "eww" from Emacs 29 source?

That's how I do this for `char-fold` (use-package char-fold :custom (char-fold-symmetric t) (search-default-mode #'char-fold-to-regexp) :quelpa (char-fold :url "https://raw.githubusercontent.com/emacs-mirror/emacs/master/lisp/char-fold.el" :fetcher url)) But in case of `eww` you may need to download dependencies like `shr` as well.

Yes it is. Org is included in emacs, but many have used Melpa to always use the latest.

You can try it, and it might work, but there's no guarantee. Any changes to eww in Emacs 29 which are utilising *other* changes to Emacs 29 are liable to make that code unusable in earlier versions of Emacs (unless you chase the dependencies and copy those changes as well). Simply clone the Emacs repository to obtain the Emacs 29 sources (currently master), and you can attempt to `M-x load-file` anything you want from there.

Basically, I wanted to use eww from Emacs 29 source. I use eww quite a lot, and recently I had to downgrade to Emacs 28.2, due to a combination of issues in Emacs; Doom; and emacs-plus@29 formula --with-native-comp flag. Turns out, several improvements are in eww that I now miss. Better fonts, better scrolling are the big ones. So I tried to cherry-pick eww from 29, and pulled the thread of the things it needs to run. Turns out, this is harder that I thought, because there's not just elisp. I started with /lisp/net/eww.el, it required new macro `defvar-keymap`. I found it in lisp/keymap.el. Loaded that, but that wasn't enough, then lisp/textmodes/pixel-fill.el, lisp/emacs-lisp/subr-x.el, lisp/net/shr.el have followed, but I got stuck at buffer-text-pixel-size, which turned out to be a C function. And I think I need to create an actual patch that I would have to apply on top. This entire shaky pyramid doesn't feel very stable and I think it's not worth it. I'll just upgrade to 29 again, since the issues that forced me to downgrade been apparently fixed. This whole thing made me once again appreciate all the work and improvements going into Emacs. It seemed that only recently Emacs 28.2 was released, but we already have so many awesome things in 29. It's exciting.

Yes it is kind of tightly integrated. That is why I feel that most functionality should be moved out and at the time of final build these core packages should be pulled. There is a move in that direction. But I guess this will take a few more years.

org is a good example. And it can be further improved. For instance, it is a manual process when the maintainer decides when to merge new version of org in the master branch. Ideally every commit in the development branch of org should be available in the development branch of emacs. Org can specify min version required and if emacs can pull it automatically from core set of modules then it would be much better. So then emacs’ build system can decide when building 28 or 29 or any other release… whether to pull org or not.

>I had to downgrade to Emacs 28.2, due to a combination of issues in Emacs; Doom; See [https://discourse.doomemacs.org/t/emacs-29-0-50-support/3241#safe-commits-2](https://discourse.doomemacs.org/t/emacs-29-0-50-support/3241#safe-commits-2). Now I've finally updated Emacs dev version with [snap](https://snapcraft.io/emacs). It's *mostly* working.

I think in a majority of cases it would be very little different to the current situation. ELPA would need to provide multiple different releases of the package to support each Emacs release (otherwise no package could ever be updated to support new Emacs features). In practice the packages supporting Emacs versions older than the current version would likely be static (because not many maintainers want to be maintaining multiple different versions of the codebase simultaneously). And for those cases, that's exactly what we already have -- download a given Emacs release and you'll get the versions of the libraries which are compatible.