move fail

src/SUMMARY.md

@@ -10,3 +10,4 @@
   - [Lifetimes](./ch04/s02-lifetimes.md)
   - [Stackless](./ch04/s03-stackless.md)
   - [Covariance](./ch04/s04-covariance.md)
+  - [Fail Semantics](./ch04/s05-fail.md)

src/ch04/s00-concerns.md

@@ -1,19 +1,18 @@
 # Concerns (questions) with the current implementaion
 
 ## There exist alternative `Functor` implementations
-
 See the [relevant subchapter](./s01-alternatives.md)
 
 ## It might be better to have a per-lifetime trait for `Functor`s
-
 See the [relevant subchapter](./s02-lifetimes.md)
 
 ## `Stackless` is kind of bad
-
 See the [relevant subchapter](./s03-stackless.md)
 
 ## `WeakFunctor::F<'a, A>` is not (yet) covariant over the lifetime `'a`
-
 See the [relevant subchapter](./s04-covariance.md)
 
+## `Fail`/`FailMonad`/etc. have unclear semantics
+See the [relevant subchapter](./s05-fail.md)
+
 ## Can `WeakFunctor` be an associated type of a `Functor` instead of its supertype?

src/ch04/s05-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 severe" than the error it receives.