How does Laravel handle a Many-to-Many relationship, when the intermediate table has non-unique FK pairs?

[StrykeSlammerII]

This is a combo Laravel/Eloquent, database design, and documentation question; any hints are appreciated!
It's a little long (4 questions total), so I'm hoping I didn't just miss something obvious. 😅

Background

I have two tables, call them Shop and FurnishingClass.

FurnishingClass is somewhat abstract--it may define classes of things, such as "Chair" and "Table" and "Dresser", but doesn't define details of individual chairs, tables, or dressers.

A many-to-many relationship furnishingsInventory seems obvious. We can even add some data there, such as Quality or NeedsReplaced for those individual items.

But what happens when a Shop acquires a second "Chair"?
All the documentation I see assumes that each row in an intermediate table has a unique FK pair, but I haven't found where that's an explicit constraint. I certainly seem allowed to construct a table where the FK pair is not unique 🤔

Laravel/Eloquent

The docs for sync() don't address this case:

$syncArray=[
    1=>['Quality'=>0],
    1=>['Quality'=>1],
    1=>['Quality'=>5],
];
$results = $this->ShopModel->furnishingsInventory()->sync($syncArray);

If I'm reading the code correctly, the above will try to update the same ->first() row three times, so it doesn't work as naively expected.

After additional thought, I see that sync actually can't work the way I'd like: if, after running the above code, we had three rows for ShopID 1, and we then tried a $syncArray with only 2 rows, how would it tell which row should be deleted/detached?
Maybe it should just overwrite the first 2 and delete the 3rd, but that's a big assumption. If there was a reason the 1st or 2nd row should be deleted and the 3rd row updated, I don't see how sync would understand that.

Sync Documentation Question

Am I reading the code correctly? And does someone mind updating the docs to make this explicit? 😁 (I'll be happy to send a PR for that myself, but first I want confirmation that I'm reading it correctly.)

Eloquent Usage Question

Is there another method that does what I'd like sync to do here?
(With the above reasoning, I'm not even sure that attach/detach will work correctly on multiple intermediate rows with the same FK pair!)

Database

Considering that I haven't been able to find much (if any) discussion with a similar set of tables, perhaps there's something obvious I'm missing with my design.
(Databases aren't my first love, I typically know just enough get by and/or hurt myself).

• One possible solution I've looked at is a ternary relationship--something like "farm out all the additional data from intermediate table furnishingsInventory to a third table FurnishingInstance". Then the intermediate table has three FKs instead of only two, and the FK-triple on each row is unique. (I don't think Laravel has a way to work with these directly, for multiple reasons.)
  • However, the ID on the intermediate table is already unique; do we really need a whole new table that's 1-1 with the existing intermediate table? Is there some missing relationship when using just furnishingsInventory? 🤔
  • If unique FK-pairs are required on each table then maybe I need to adjust my relationships, with an additional intermediate table somewhere? But FurnishingClass is still one-to-many with FurnishingInstance, and Shop is still one-to-many with FurnishingInstance. It's just that the FK pair isn't unique.
• I could also treat it two full-fledged one-to-many relationships, and deal with the middle table directly rather than infer it as an intermediate table. 😬

Database Question

What is best practice for this type of relationship, and is there anything special I should know about using Laravel/Eloquent with it?
(Don't need a long answer here, just confirming what terms to search for would be helpful)

General Documentation Question

Considering that I'm posting a github discussion about this after failing to find an answer, can the Laravel documentation be clarified?
(A short note about the accepted answer here may be enough. Again--I'll be happy to write up that PR, assuming I didn't misread something that's already there!)