The implications of Pijul are really interesting. Some of the guarantees afforded by Pijul's model are clearly superior to those afforded by Git, but I can't help but get the impression that Pijul is:
1. considerably more complex under the sheets, and
2. considerably more complex in situations you're going to have to deal with as a user.
It would be nice to read an article from someone familiar with Pijul, that would take a look at the "ugly" (from the user's perspective) parts, and either explain how they aren't issues in practice, or at least show how you would handle them and argue why the benefits outweigh the costs.
For example, accurately representing repository states with files appears difficult: the page on Pijul's theory[0] explains how Pijul does not limit the repository to containing valid states, and mentions that "...else, we say the file has a conflict, and presenting the state of the file to the user in an intelligible way is not obvious.". There's an independent article about Pijul[1] that gives some examples of how you could end up with two different conflict states in Pijul that render into identical files.
I also had a look in the patch list for the master branch[2]. I managed to find a few patches I couldn't understand by looking at them. I realize that Pijul is still some ways from being ready for mass consumption, but the selling point of Pijul is its theory of patches. The documentation for "pijul patch"[3] notes that outputting patches as text "may lose information", and that "the text representation is merely a pretty-printed representation, and is not sufficient to apply the patch". This suggests to me that the difficulty in viewing those patches is at least partially due to viewing Pijul patches being a hard problem.
Here's an example, "Fixing a conflict with #387": https://nest.pijul.com/pijul_org/pijul:master/patches/6E7Kee...
Some lines at the top appear to be for informative purposes. They reappear later on, but slightly different (e.g. imports reordered, or with changed whitespace), and without any color (green or red) that would indicate that they were added or removed. They're shown in a context (e.g. line 219, 222) where they fit in as additions together with other lines that were added, though. The output of "pijul patch" for this patch[4] looks somewhat similar, and likewise not very easy to digest.
I really want to like Pijul, but I'm worried that it's too powerful and requires too much from the user. I would like to be wrong, though, so I would really welcome an article explaining these "darker" sides.
0: https://pijul.org/manual/theory.html
1: https://jneem.github.io/pijul/
2: https://nest.pijul.com/pijul_org/pijul:master/patches
3: https://pijul.org/manual/reference/patch.html
4: https://pastebin.com/b8XT5WPE