Yes, but that doesn’t matter as the logical update view semantics tell us that a clause that is added after we started the goal cannot be backtracked into 
So it is simply if we hit the last clause of the relevant clause set we do not need a choice point (unless debug mode is enabled). The notion of relevant clause set is sometimes a compile time decision and sometimes a runtime decision. The documentation on clause indexing is fairly explicit about that. Still, this is not set in stone. Future versions are likely to improve on that as avoiding choice points is crucial in allowing for both logically correct and efficient code as it allows for deterministic code if the call is sufficiently instantiated and logically correct non-deterministic code if this is not the case. Creating and quickly killing a choice point is only painful for nearly trivial code. For anything doing a bit more work it doesn’t matter too much. What does matter is leaving choice points open for a long time. That prevents last-call optimization which is slower to begin with (but again, this doesn’t matter too much) but notably prevents old data to be garbage collected, making memory grow quickly and causing garbage collection time to grow (GC is linear in the size of the reachable data).
And of course ;/2 as well as various built-in predicates created choice points.