Yes, that text is somewhat misleading. I have submitted enhancement request 1652693 for Oracle to introduce a different error number and error message for library-cache self-deadlocks.
You problem looks more like the incremental export bug, than the snapshot (null refresh optimization) bug. However, you could test the theory easily enough by getting the patch for bug 1376209 and setting event 32333 to disable the null refresh optimization. There is a note about this in this month's Ixora News. See this old answer for more about the incremental export bug.
You state in answer to a question that the 4020 error is a library cache deadlock, not an enqueue deadlock. Does this mean that the boilerplate text in the trace file which says:
"A deadlock among DDL and parse locks is detected.
This deadlock is usually due to user errors in
the design of an application or from issuing a set
of concurrent statements which can cause a deadlock.
This should not be reported to Oracle Support.
The following information may aid in finding
the errors which cause the deadlock:
ORA-04020: deadlock detected while trying to lock object SCHEMA.TABLE_NAME"
is erroneous? Can a self-deadlock 4020 error really be caused by application
design errors? Oracle is throwing this back at us, saying it's a design issue,
when I think we are encountering a bug. I've seen some discussion on your site
describing some self-deadlock scenarios where these occurred due to a share lock
being held which should have been released, preventing acquisition of an
exclusive lock, for instance involving a stored procedure/package/etc which
required recompilation.
Briefly, in our case, the first insert into a table following a restart of the database sometimes self-deadlocks with a 4020. I think it has something to do with a snapshot log on the table being inserted into. After the first occurrence of the error, subsequent inserts are successful. Do you think my theory plausible?