I would interpret the message as a deadlock on some combination of Lock resources or Communication Buffer resources. “Lock resources” are ordinary object locks, and “Communication Buffer resources” are exchangeEvents used for combining results of parallel queries. These are described further in https://blogs.msdn.microsoft.com/bartd/2008/09/24/todays-annoyingly-unwieldy-term-intra-query-parallel-thread-deadlocks/ where the relevant paragraph is:
An “exchangeEvent” resource indicates the presence of parallelism operators in a query plan. The idea is that the work for an operation like a large scan, sort, or join is divided up so that it can be executed on multiple child threads. There are “producer” threads that do the grunt work and feed sets of rows to “consumers”. Intra-query parallel requires signaling between these worker threads: the consumers may have to wait on producers to hand them more data, and the producers may have to wait for consumers to finish processing the last batch of data. Parallelism-related waits show up in SQL DMVs as CXPACKET or EXCHANGE wait types (note that the presence of these wait types is normal and simply indicates the presence of parallel query execution — by themselves, these waits don’t indicate that this type or any other type of deadlock is occurring).
The deadlock graph for one of these I’ve seen included a set of processes with only one SPID and a graph of objectlocks and exchangeEvents. I guess the message “Transaction (Process ID 55) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction” appears instead of “Intra-query parallelism caused your server command (process ID #51) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1)” because of the combination of objectlocks and exchangeevents, or else the message has been changed in SQL Server since the article was written.