s01-fail.md

src/SUMMARY.md

@@ -6,3 +6,4 @@
 - [Implementation]()
 - [Usage]()
 - [Current Implementation Concerns](./ch04/s00-concerns.md)
+  - [Fail Semantics](./ch04/s01-fail.md)

src/ch04/s00-concerns.md

@@ -9,3 +9,6 @@
 * Prevents using varied hash sizes.
   * Prevents using dynamic hash sizes.
 * Not a context-specific constant because associated `const`s in `const` context are unstable.
+
+## `Fail`/`FailMonad`/etc. have unclear semantics
+See the [relevant subchapter](./s01-fail.md)

src/ch04/s01-fail.md

@@ -0,0 +1,16 @@
+# Fail Semantics
+
+## Lack of proper support for injecting errors into classes that are already `Fail`
+* Classes have only one implementation of `Fail` per error type.
+* Proposed solutions:
+  * Have `Fail` as a separate trait with the error and the class as associated types.
+  * `OverloadClass` to mix-in additional `Fail`.
+
+## Lack of support for strict ordering of errors
+* Current (possible) implementations of having one error or another either allow short-circuiting
+on only one of them, or give them both the same priority.
+**Right now this model is considered the main one**,
+i.e. this restriction may get stabilised and standardised at some point.
+* More complex behaviours are expected to require a more complex execution model, with states
+taking messages from other states and optionally dropping their own execution, if their
+result\['s error\] is guaranteed to be "less sever" than the error it receives.