No, thanks.

TL;DR … I don't have answers, just more questions.

Some want a whole OS in the browser, others want it to do only HTML and code everything in it.
Wait!
Isn't the HTML-only browser an OS in HTML then?

Convergence of features means convergence of attack surface.

I think both strategies will converge in functionality, and that way the attack surface will converge too.  If you "emulate" your favourite external applications in "active" HTML1337-extensions, they will be able to do the same harm as your external "PDF-browser (with JS)" sure can do too.  I'm not looking at browser sandboxes now, because you could do the same with chroots, jails, containers, VMs in your real(?) OS too.

You download a PDF with JS internals, a LibreOffice spreadsheet/document with active parts or even an Emacs/Org/Babel text with executable Babel blocks inside and you may have an unwanted surprise soon.

The problem isn't the embedded PDF viewer with JS, the problem is allowing possibly dangerous functionality by default.

# local variables:
# visual-line-mode: t
# org-babel-noweb-wrap-start: "«««"
# org-babel-noweb-wrap-end: "»»»"
# org-confirm-babel-evaluate: nil
# end:

Sure that's (config vars at end-of-file, only one of these lines is a danger) neat with your private texts, where you know which text contains which active parts, but in this example Emacs will ask at loading time.  It you put the same setting in your Emacs startup, it won't. Will you always read that config vars list Emacs wants you to confirm or just semi-automagically type the spell to allow continuing?

While clicking on foreign stuff you typically won't have the knowledge which stuff contains harmful contents and which doesn't.  But will a question "Allow activating feature XYZZY for this text?   [yes] [no] [always]" really help?  How many individual "[yes]" clicks will it cost until René Average will click "[always]"?

Why have a walled garden, while letting everyone or everything inside?

But now for something completely different?

Smart folks still live in caves and fire is their newest achievement.

Or: It isn't that simple.

If we would declare (TeX's) DVI files with links inside as default format for the web, sure lots of users would call for helpers to get active parts too.  The development would repeat with just a different base format. There is some deeper problem/demand involved.  Maybe Sasha Average looks at computer screens as new TVs?
They have to be wriggly and make sounds?

There is a demand for these features, and so we need to find ways to present them in a safe way, or at least, as not everyone is coding, should find ways to demand them being implemented in a safe way, and the right to make providers of unsafe stuff accountable for their damage.

We need the data cattle uprise...

I'd prefer a world where I don't need to wall and lock my house and garden.

...but that may stay a dream.

Licenses wars again?
Please put that into an own thread.

FTP is a DilloPlugIn: https://hg.dillo.org/dillo/file/tip/dpi/ftp.c

/*
 * Dpi for FTP.
 *
 * This server checks the ftp-URL to be a directory (requires wget).
 * If true, it sends back an html representation of it, and if not
 * a dpip message (which is caught by dillo who redirects the ftp URL
 * to the downloads server).
 *

I've playing with Dillo on my to do list because of its easy looking DPIs, but still some other topics have a higher position there.

Several stuff normally directly baked into the browser is realised as DPIs in Dillo:

—▷ https://hg.dillo.org/dillo/file/tip/dpi

And externally developed DPIs don't look sooooo scary...

—▷ https://github.com/boomlinde/gemini.filter.dpi

Read about the history of browsers.  They were meant as unified frontend to access information scattered around the net being accessible via many different protocols.  THAT is the way the web was born.  Many sites used FTP servers to present their documents.  And Gopher was very common back then too.

If protocol diversity is torn down, the web loses lots of dimensions, one for each discarded protocol.  And it already has lost so many of them, if viewed via mainstream browsers.

But there still are some browsers that offer a lot of protocols.

Look into elinks's features.conf for what all you are missing while using a mainstream browser!  Even FINGER and FSP are supported, and serverless local CGIs (W3M can do that too and implements a filesystem view and 'w3mman' as local CGIs), which turns such a browser into a standard frontend for own scripts.  Read that as 'file:///cgi-bin/...'.

Dillo has a simple plug in system, that looks like even a text mode fossil like me could be able to write add ons for other protocols.  This Gemini plugin for Dillo demonstrates it in Go.

And sure there is Emacs with different add ons to browse the web (Eww and siblings), but most of them are a bit lacking. OTOH via Dired+Tramp you get file systems access even to remote systems, Elpher does Finger, Gopher and Gemini, Magit can be seen as Git browser, with Eshell+Tramp the world is just a "cd" away, browsing into several archive formats (e.g. (Surprise: Emacs includes more than one editor plugin too!) transparently edit stuff in ZIP files) is naturally, four different "IRC browsers" are known, mail, news, jabber, ... Emacs is a browser!  Well... the renderer for HTML needs an overhaul... can you help there?

Browsers should unite the different dimensions (protocols, text formats, renderers) of the nets instead of being divisive.  And here I'm looking especially at the single protocol browsers for only HTTP+HTML, only Gopher, only Gemini, ...
Don't do that! That's divisive and considered unfriendly and may create locked in syndromes.  Ok, or at least it is very ugly, if we need a different program for viewing each (protocol,text-representation) combination.

Don't allow ${THEM} to turn the net/web/mesh into a one dimensional string!

I̶n̶t̶e̶r̶n̶e̶t̶?̶
A̶l̶w̶a̶y̶s̶ ̶o̶n̶?̶
UUCP!

Real minimalism means EMACS!

I'm waiting for systemE to get stable.

Or use a nice and easy language that was made especially for numbercrunching:

#!/usr/bin/dc -f
_2.1sx0.7sX_1.2sy1.2sY32sM72sW23sH8k[q]sq0sh[lhlH=q0sw[lwlW=qlXlx-lW1-/
lw*lx+sRlYly-lH1-/lh*ly+sI0sr0si0sa0sb0sm[lmlM=qlalb+4<q2lr*li*lI+silalb
-lR+srlm1+smlr2^sali2^sbl0x]s0l0xlm32+Plw1+swl1x]s1l1xAPlh1+shl2x]s2l2x

BASH can do "more readable" than expr:

#!/bin/bash
#
# ###surprise### in bash
#
# 20131116      start.
#

((xmin=-8601))  # int(-2.1*4096)
((xmax=2867))   # int( 0.7*4096)

((ymin=-4915))  # int(-1.2*4096)
((ymax=4915))   # int( 1.2*4096)

((maxiter=30))

((dx=(xmax-xmin)/72))
((dy=(ymax-ymin)/23))

C='.-+co%#'
((lC=${#C}))

for((cy=ymax;cy>=ymin;cy-=dy)) ; do
        for((cx=xmin;cx<=xmax;cx+=dx)) ; do
                ((x=0))
                ((y=0))
                ((rsq=0))
                for((iter=0;iter<maxiter && rsq<=16384;iter++)) ; do
                        ((xn=((x*x-y*y)>>12)+cx))
                        ((yn=((x*y)>>11)+cy))
                        ((x=xn))
                        ((y=yn))
                        ((rsq=(x*x+y*y)>>12))
                done
                ((c=iter%lC))
                echo -n "${C:$c:1}"
        done
        echo
done

Would grabbing the deb-src from RasPIan and rebuilding it on Devuan work?
You'd have a deb (apt-ftparchive?) then for a local repo () or to dpkg -i it.
You'd notice incompatible updates then, which you won't get if installed without the OS's knowledge.

Why not just use qemu-system-x86_64 -enable-kvm or qemu-system-i386 -enable-kvm directly?

How that?
I think I definitely know which of my penguins have caught the systemd flu and which have not.