There are a few situations in which emake will not record history for conflicts. I don't think it's possible to give you an exhaustive list of all such scenarios, but I will try to give a few examples that will hopefully satisfy your curiosity; if you have a specific scenario in mind, please do provide details on that so we can help you understand whether or not the conflicts you see should be resolved, or if the behavior you see is in fact a product defect.
The first thing to remember about conflicts and history in this context is that history is generated based on the usage of the rerun job, not the original conflict job. That means that if the job behaves differently in the rerun than it did in the original run, emake will not generate a history dependency. This is an unusual situation, but it can pop up if your build has some non-determinism in its behavior, or if it is dependent on external inputs that are not tracked by Accelerator (database content, for example), or if the rerun job ends up doing nothing as in this example:
all: foo.h foo.c
%.h %.c: ; touch $*.h $*.c
foo.c: ; touch $@
Another possibility is that the conflict is over something other than the filesystem state. An example of this is conflicts over the gmake stat cache, which is part of emake's GNU make emulation. Here's an example that will sometimes produce conflicts, even with a good history file:
OBJS=1.o 2.o 3.o 4.o 5.o
all: test.a($(OBJS)) ; @echo done
%.o : %.c ; touch $@ && sleep 1
(%): % ; $(AR) $(ARFLAGS) $@ $<
(note that in this case, the best solution is actually to add a rule that does all of the archive updates in a single go, like this
test.a($(OBJS)): $(OBJS) ; ar rv $@ $^).
That's just a sample of the kinds of things that can cause conflicts that don't resolve even with a good history file. Again, if you have a specific scenario in mind, please start a new question with details about that scenario so we can help you understand the behavior you're seeing.