I think that 'shell' is a semantically coarse word that highlights semantics of enclosure,protection, (maybe thinness) that stuck , and latter its usage was reinforced of the proliferation in unix-textbooks of the classic image of the shell encircling the kernel.

We could of course still use that word but i think the semantics of the 'shell' are not align with the way we use the process 'shell'.

The 'shell' is the default process that a computational system presents to its human user by default.

A user can use the 'shell' to set up workflows of processes.  A user can also automate by scripting workflows of processes.

So i think the 'use' entails semantics of control, management , coordination , language intepreter , admininstration , human interface , mediator.

In that context even CLI seems semantically more corect. But still missing some central semantics.

Surely the 'shell' does NOT encirlcle the 'kernel' . A user process started by the shell or automatically when the system boots also is close to the kernel services.

So a 'shell' seems to be a user process that is best suited to a task that others are not. That task is workflow setup , management and control.

context : devuan packages / nvidia-driver @
               devuan wiki / nvidia gpus @
               devuan forum / Installation > How to install nvidia drivers in daedalus? @
               debian wiki / NvidiaGraphicsDrivers @
               wikipedia / List of Nvidia graphics processing units @
               nouveau / codenames @
               debian package tracker / glmark2 @

After installing nvidia driver in Daedalus i took the chance to perform a couple of benchmarks
to see how libre nouveau performs relative to propriatery nvidia gpu drivers.

I use two benchmarks : glmark2 and unigine's Valley 2013 .(Superposition 2017 wasnt executing with nouveau)

$ inxi -G
Graphics:  Device-1: NVIDIA GM206 [GeForce GTX 960]

Unigine Valley Benchmark 1.0

System
Platform:     Linux 6.1.0-33-amd64 x86_64
CPU model:     Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (3597MHz) x8
GPU model:     NVIDIA GeForce GTX 960 PCI Express 535.216.01 (4096MB) x1
Settings
Render:     OpenGL
Mode:     1440x900 fullscreen
Preset     Custom
Quality     High'

FPS:     99.8
Score:     4176
Min FPS:     43.3
Max FPS: 167.8

FPS:     10.8
Score:     452
Min FPS:     7.5
Max FPS:     16.5

glmark2 Score: 842
glmark2 Score: 17719

Something else that i would like to benchmark is the time it takes dekstop process to open their window.
It seem to me in nouveau the window took more time to appear.

ps : I align here with a mainstream mentality that focus on certain aspects of a software use. But from another
libre distro community perspective thinking in terms of community workflow integration , security , not to mention
of course the ability to study and alter the code the nouveau would be a better choice. Of course i cant help to
wonder why some libre projects like X server , nouveau seem so sterile in terms of forks in contrast with other
areas like window management. I would make a first guess that the more closer you get to the hardware the
less flexible a programmers becomes.

A package is a social software. @.

It needs libraries , and it may suggest other software.

But when a Devuan user establishes a certain workflows it creates also dependecies among software (and among file-types).

So i propose a format for curared - eso-devuan workflows where user can publish those interdepencies.

eg:

apt-get install-workflow  johh:lowlevelrprogramming
apt-get install-workflow olga:digitalpainting-begginer

Version: Daedalus

In XFCE installing a programs like Hexchat , Firefox i can see them in the app menu .
If a switch to a wm like pekwm or jwm i can see a Debian menu with some apps but i neither Hexchat or Firefox are in the app menu.

I know there is a related standard Desktop Entry Specification.
I wonder jwm and pekwm are the ones that dont follow the standard.

I think there are various idiosyncracies in apt utilities that hinder their use.
I must do work(1) before using one tool or one of the tool options to be sure
if it uses glob or regex and if it tries to substitute the first with the latter
if the first wont be successfull. And of couse in doing that (using
a failed glob as a regex) more idiosyncracies creep in.

Also that is one class of idiosyncracies (argument type handling) .
I had (have) issues with not knowing what is exactly the search
space of a certain argument . Does it search the package name only
or also in other fields ? My experience again warns me to be
cautios and investigate further many times.

I would hope a utility could be more transparent toward
the sysadm about what type of argument it accepts and
what it does with that.
I wonder if such an endeavor would interest anyone. Also
i wonder if the language implementing the utilities hinders
or not a less frictioned use.

(1) And by work i hopped it meant just looking up the man page .
I find my self doing various tests to understand what happens
in each case.

--------- examples ---------
-------------- search space idiosyncracies ------

$ sudo apt-cache -n search  '.*aa$'      / although i used -n  apt-cache give me in the result package names not matching my regex.

-------------- pattern type handling idiosyncracies ------

$ sudo apt-cache  policy  'freeb.*'     / uses regex
$ sudo apt-cache  policy  'freeb*'      / uses glob
$ sudo apt-cache showpkg '*aaa*    /
$ sudo apt-cache showpkg '^aa.*' | grep '^Package'      // regex

$ sudo apt-get install pattern          / will report in its result if it uses the pattern as a glob or as a regex.  Which i found it helpfull.