I'll toss in an opinion on the "why two separate tables" question.
First and foremost, I've made it clear that I'm a pragmatist, not a purist. However, if the notes are about two different things then for purity of normalization they should be in two separate tables. Consider this by working forwards from what this COULD have been (and maybe once was?)
It would have been possible to have a single, updateable vendor 'notes' field in the vendors table, and a single, updateable item 'notes' field in the items table. Since vendors and items are clearly separate entities, they each need their own tables. Then, per good normalization principles, everything about items would be in the items table, and similarly for vendors. So the notes would follow along with their related entities.
Fast-forward to the day when you realize that you might need to change the notes by splitting them into a pair of tables in a parent/child one/many relationship. But the item notes still belong to items and the vendor notes still belong to vendors. Based on the original separation of entity attributes, these (now extended) attributes still belong in separate tables.
Pat stated this next point eloquently in post #2. I'm just offering different words in hopes that it strikes the right note. The FK that links the notes to their parent entities would violate a basic normalization concept if you merged the two notes tables into one. That FK would no longer uniquely identify the specific entity to which it belonged, since one could easily imagine that the PKs of the two tables COULD be autonumbered keys. Which means that an FK of 12 might be item 12 or it might be vendor 12. That relationship would really mess you up for trying to maintain relational integrity, since it would ALSO be possible to have item 200 but not have that many vendors. So RI would both fail and succeed at the same time on the same record. To establish the relationship, Access would require that the FK has a corresponding PK, and an answer of "it does and it doesn't" won't work at all.
The principles of database normalization aren't intended to combine things by merging them but are rather intended to separate things based on their differences of intent or usage. The mechanical point of that separation is so that using simple keys you can use queries to rejoin things in separate tables when you need them to be rejoined, but you can leave them not joined when your operation doesn't require that extra information. For example, a vendor-centric report probably has no need to see an item's notes, because items (if treated at all) will be treated in terms of aggregates thereof.
But let's take the ultimate worst-case requirement for a "pure" Access BE. What do you do when the file gets so big that it becomes impossible to manage via simple Compact & Repair? We've had a few cases of that situation on the forum. It happens when the file gets above about 1.5 GB.
One solution is to remember that Access CAN deal with more than one BE file at the same time. So you would split the BE into multiple BE files. But if you had merged those Notes tables, you just made it a pain in the toches to perform that split.
That is one old philosopher's answer to WHY you would use two Notes tables.