KOutliner

   1. First impression was, "I have org-mode why do I care about this?"

     1a. Annoyed that "it isn't org-mode."

       1a1. Key bindings like C-j instead of Alt-Ret.

   2. I do like that each "cell" has its own path. It is possible to
      say "go to cell 1.2.3" or "1b3," wheras in org you can only go
      to a named headline.

     2a. In a sense org is designed to be used with yet more tools. Tools
         like counsel and helm make it easier to select nodes
         interactively when you go to refile or such.

     2b. These tools are powerful but add more complexity to the emacs
         installation.

   3. Easily broken, tries to be clever

     3a. In org what you see is mostly all there is. Then formatting
         operators are used to make parts of that pretty. And code
         folding is used to hide things you don't want to see. There
         are fragments of ex. "property drawers" here and there.

     3b. org is basically a helper that edits text that looks org-ish,
         but hides nothing from you unless it's been asked to. You can
         easily create and manipulate structure with non-org functions
         as long as they "look org-y" in the end.

     3c. Kotl wants to take things over and misses a few
         spaces. Sometimes when creating a new node while in a node
         with multiple lines, you will get another node element in the
         wrong spot. The clever editing routines then prevent you from
         fixing the markup.

   4. Uses up some of your magic

     4a. Kotl consists of separate header, content, data, metadata
         pages which are hidden using narrow. This means you cannot
         use the narrowing for your own purposes, as one can do in org
         to focus on particular subtrees.

   5. Based around the NLS/Augment design

     5a. I think this is where kotl really starts to make more
         sense. Compared to org-mode it is not that special. Org had
         more utilities, more support, recognition, even some tools
         outside of emacs support it. But NLS/Augment is about
         paragraph-level "statements" and not big headlines with contents.

     5b. For example in org you can link to a headline, and possibly
         use unique ids to track headlines as they get refiled
         around. But the contents of those headlines does not exist
         from a logistical standpoint.

     5c. In kotl and in NLS/Augment, each "statement" or paragraph is
         it's own "headline." This does not strictly matter up front.

     5d. Where each thing having its own identifiers starts to matter
         is that you can link between one paragraph to another
         paragraph and that link stays alive when the paragraph is
         moved around in the document.

     5e. So strictly kotl is worse; it does not do TODOs like org does
         unless you bring your own scripting. It does not have all the
         extreme navigation aids like helm-org-rifle. It does not have
         extensive support to publish documents or outlines with.

     5f. Kotl becomes interesting instead through the lens of
         NLS/Augment: when conjoined with the "buttons" support of
         hyperbole and other documents written with those buttons in
         mind.

       5f1. You write documents in outlines such that each paragraph
            is numbered. Those documents then explain some particular
            thing and perhaps they cite other things. The citations
            are implicit or explicit "buttons" which link back to say,
            an e-mail message thread where some decision was made. The
            outline then ties all the relevant messages together with
            buttons and is itself a new document that can be referenced.

       5f2. So think org-mode, but each paragraph silently has its own
            UUID that can be linked to from anywhere else in the
            project.

   6. Uses serial numbers to identify all things, but then also has
      relative paths.

     6a. These are written to the file but hidden through emacs
         magic. So each bullet point actually begins with some "0145"
         type number and then the contents of that cell.

       6a1. The leading zero signifies an absolute ID.

     6b. Unique serials identify the bullet point, content and
         structure (via indentation) but meta-data is kept on a
         separate hidden "page."

       6b1. The meta-data is a list of s-expressions which hold the
            serial number for the cell they refer to.