As brought up in #182 , and discussed in person, the `History` should always carry a dummy column at the first position, indicating, that nothing is done yet. The problem is, that this first column is not set consistently and is missing, when a new `Flags` object is initialized from an existing one. In order to get a missing feature into the translation schemes (!237), I tried to fix this issue. Unfortunately, the initialization and checking of the `Flags`/`History` object is somewhat convoluted and the call chain triggered not straight forward. After putting in several hours resulting in a bunch of working but unsatisfying hacks, I'd like to give this task back to the original author @palmb. To summarize the necessities: - `History` should **always** carry a first columns (usually set to `UNFLAGGED`), no matter how they are initialized - We **should not** have multiple initializing columns as a result from repeated `History` creation All in all, I'd think, the `Flags` and `History` needs a bit of a cleanup. I especially stumbled upon the initialization: - The function `initFlagsLike` creating empty `Flags`and correct `History` - The method `_initFromRaw` creating non-empty `Flags` with incorrect `History` IMO it would make sense to bring both to the same level, e.g as `classmethod`s and somewhat streamline the value checks (maybe make `_initFromRaw` call `initFlagsLike`).