Designed in the early stages of Prolog, assert and retract have been overloaded with different and often conflicting requirements. They try to be both the way to implement permanent data structures for global state information, self-modifying code and tools for Prolog program management. This created not only well-known semantical but also expressivity and efficiency problems.
This unnecessary overloading is probably due to some of their intended uses in interpreted Prologs like implementing the consult/1 and
reconsult/1 code-management predicates that can be replaced today by general purpose makefiles. As a consequence, their ability to express sophisticated data structures is very limited due mostly to unwanted copying operations (from heap to dynamic code area and back) and due to their non-backtrackable behaviour.
For example, to ensure indefinite number of uses of an asserted clause most Prologs either compile it on the fly or do some form of copying (usually twice: when asserting and when calling or retracting). This is not only a waste of resources but also forbids use of asserted clauses for dynamically evolving global objects containing logical variables, one of the most interesting and efficient data structure tricks in Prolog. Worst, variables representing global data structures have to be passed around as extra arguments, just to bore programmers and make them dream about inheritance and objects oriented languages. This also also creates error prone maintenance problems. Just think about adding a new seventh argument to a 10-parameter Prolog predicate having 10 clauses and being called 10 times.
Those are the main reasons for the re-design of these operations using BinProlog's blackboard.
Objects on the blackboard have indefinite extent. However, their names are "rigid designators" that can change their reference. Data objects do not disappear just because they have no names anymore. This is the main difference with variables in languages with destructive assignment. If the garbage collector "can prove" that an object or some part of it is will never be used again, the space will be recuperated automatically. Although objects cannot be "changed" they can be further instantiated as it happens to ordinary Prolog terms.
Efficient access to objects on the blackboard or part of them is based on an efficient 2-key hashing table, internal to BinProlog's run-time system.