Probably. I’m not yet too familiar with how Pijul works. I envisioned
- Some change A is made.
- Some change B is made.
- Shortly therafter, an incompatibility between A and B is discovered.
- The discoverer offers a patch marking patches A and B incompatible.
- The maintainer pulls this patch, thereby acknowledging the problem.
- A patch is made that solves the problem and marks the conflict as resolved.
Though I can imagine a repo management platform being a better place for such functionality.
Do you mean would (as in will always) or could (as in will in some cases)?
Which patches exactly would these cathedrals consist of? All ancestors? All descendants? Other patches?
That’s why I wrote “effecting” the regression and not “causing” it. 
Exactly, they are unrecorded. And in general they must be unrecorded, in the same way your “hidden error” example lead to an unrecorded bug that even git-bisect could not reliably detect.
Semantic dependencies are not well-defined concepts. You will never be able to capture them with a formal construct like git or pijul. We are not talking about capturing those semantic dependencies. We are talking about the mechanisms that Pijul will need you, the developer, to apply to achieve your goal. And we talk about which tools the developer will likely want to have to apply the necessary mechanisms.
The supposition was that two strands of features independently develop for a while and for some reason, they both use changes very early on, on which the project has agreed to mark them as conflicting. Now, a lot of work has been invested into two features that cannot be merged into the main project.
This does not look like a useful feature.
Also, marking two arbitrary changes as (semantically) incompatible is based on an arbitrary choice. The functionality of that incompatibility is not derived from the code that is inside both changes, but from looking at the code and deciding on behalf of Pijul that these two are, in fact, incompatible. The downside of this is, that it opens the door to reject code for political reasons, not for factual reasons.
Strictly sorting by date contradicts the “pull order” that is used now.
Consider merging a feature into the code base which has been in development for a long time. Where should its oldest changes, which are certainly much older than the recent changes of the main code base, go? Should the be distributed across the timeline according to their date? Or should they stay grouped together by the feature they represent?
Date is an okay-ish indicator for a repository state (it works very well for large time frames, like years, maybe months) but frequently fails when it comes to allow for an exact change-to-change discrimination (because dates, especially authoring dates, can be reversed).
Regarding auto-tagging: Should the code base be re-tagged after the merge of the feature, because the timeline changed? Maybe, it is better to get accustomed to manually tagging the code base before a merge. Because a tag can be pushed to and pull in by others, tags can be easily communicated when a common state needs to be re-established.
No, it doesn’t. Being able to do both would be a benefit in different situations.
Are you referring to the log? Or a tag? Or a channel?
I personally think that once a change is recorded, it should keep that same date and author regardless of the location of it. Since Pijul doesn’t really do “version control”, it should at least do top notch “change management”. A feature that was developed separately over a year, when pulled into the main repo should show the actual dates of each change over that year. Perhaps there should be a pre-pull auto-tag.
The log should show the history by date and by dependency.
I suggest auto-tags because the tool should do the work, not the human. And there should be a way to look at the repo by date and major event (like pull or push).
Yes, that is, what I meant to say. You would need both, having only date sorting would contradict the pull order.
I am referring to the changes in the feature, that is to be merged.
That is what’s happening right now. It was never the question to change that.
Yes and that was not the question. The question is about representation. In a log, which is a list, you must order your changes. Currently they are ordered by the time they are pulled and by their dependency. This is often also the order by time but not always.
The GIT log is strictly ordered by dependency, nothing else. Where is the value in ordering by date? Maybe, it lies in ordering independent graphs of changes by date. Because there is really no other criterion to go on.
Hm, yes, they would work similar to merge commits in GIT, just that they would point to the state before the merge and not after it.