Author here: sorry if the "append-only" analogy went a bit upstream in the comments, it was certainly meant to be taken with a pinch of salt.

All of regular programming methodologies apply with b-threads. And most of the time changing requirements would require one to change the b-threads involved in that requirement. The append-only analogy was really more to showcase the feature of incrementality.

Technically one can develop a complicated system just via append-only but again you'll likely better off having clean b-threads that deal with specific behavior organized in specific and clean ways the same way we organize any other software.

From the comments it seems I wasn't successful at highlighting the key insights of this paradigm. One read that I suggested in this article that does a much better job at explaining these concepts is "The quest for runware: on compositional, executable and intuitive models" [1] where the authors essentially describe the need for something like Behavioral Programming (authors are the creators of BP). Some quotes from the paper:

> As mentioned earlier, it will be possible to represent new requirements, or changes thereof, in a new behavioral component or module, with minimal change to the previously specified parts of the model, and without sacrificing executability and manageability. Such modules will be simply added to the existing model, virtually ‘piled-atop’ it, with no component specific interface, connectivity, or ordering requirements.

> In our vision, the units of the specification and models
are not assembled in detail like resistors or chips on a computer board, or methods and fields in an OO-programming object class. The interweaving of behavioral modules will be
facilitated by their reference to common aspects of system
behavior described using shared vocabularies (for example,
common events), and not via mutual awareness and direct
communication between components. From the point of view
of such a module, the other modules could be transparently
replaced by new ones. In fact, the implementation of any
part of the specification or a model should be replaceable by
some kind of ‘invisible box’, whose implementation remains
a mystery, and the effectiveness of the remaining modules and
the integrity of the overall system behavior will be preserved.

And from the conclusion:

> What will happen if and when the human way of
expressing requirements for systems will become almost
indistinguishable from the way this is done with computer
programs? And what will be the result of a level of compositionality that would allow humans to add capabilities to
a system with much less dependence on that system than is
possible today?

> When a collection of specification units grows over time,
accumulating an unmanageable collection of patches, exceptions, and enhancements, it is likely developers will call for
merging or refactoring them into much more concise artifacts. The new modules will replace the existing collection in all its uses (final executing system, official record
of the specification, and means for communication between
humans) without changing other parts of the specification.
Such refactoring will be acceptable, even if it ends up being
done manually, as it will focus on capturing the human’s
revised perception of the affected behavior.

1. http://www.wisdom.weizmann.ac.il/~harel/papers/Runware.pdf