If I complete these steps:
1. Create repos B and A
2. Commit file foo to repo B (this becomes cs1)
3. Create xlink /b in repo A as -> cs1@/main@B (writable)
4. Create branch /main/task001@A
5. Checkin several files without touching /b

I can then complete my task branch like this:
6. Switch workspace to /main@A
7. Merge from /main/task001

After this, B will still have only one branch and one changeset, because no changes were made inside of /b. Wonderful!

Alternately, I can complete my task branch like this:
6. Merge-To from /main/task001 into /main@A

This is a better process. It has fewer steps. In fact, it is recommended by the Plastic Book. Unfortunately, while it should behave exactly the same, there's a small difference: This process has just created a new changeset #2 on repo B that is a merge from cs1 and contains nothing.

This empty commit is dangerous, because Plastic doesn't support making empty changesets and therefore doesn't account for them in many of its behaviors. Just today, I had done the following:

1. merge-to from /main/task123 to /main (xlink gets cs:N+1)
2. merge from /main to /internal (this didn't change the xlink, it still points to cs:N, which is probably a bug)
3. Modify contents of xlink
4. Attempt to commit

The result is that Plastic sees we are on cs:N but cs:N+1 exists, so it stops the commit and demands that N+1 is merged into N first. However, because N+1 contains no changes, the merge cannot take place. The checkin is impossible until I shelve the changes, change the xlink to point to N+1, reapply the changes, and try to commit again.

It is also a problem that if you merge-to /main into /task003, for example, you will also get an empty changeset on a newly created /task003@B, which clutters the B repo. That's particularly bad if B is sync'd to a public Git repo.