You don't specify exactly how the field is used on the User and Node Entities, but I'm assuming a User is able to pick a category of content to like/see/follow/associate with using a Term reference field, and Nodes are able to say they belong to two of these categories in the same way.
I would go with two different fields, because you really have two different use cases for a reference to one or more Terms in the same Vocabulary. I don't think it would make sense to filter users and nodes based on the same field in Views anyway, because it wouldn't work the way I think you want it to work.
Using the same Field on two different content types does not in any way actually link them together, or even imply they can be linked together. It just means those two content types needed the same settings for a Field, so why not create two instance of the same Field settings to make sure they'll always be the same.
In other words; "That's not a bug, it's a feature!"
When creating a View, one of the first things you do is to select the "base table", ie you're creating a Node (actually known as "Content" in Views) or User type View. Assume you want to display "every" item of this type (SQL's SELECT * FROM foo
). If you create a Node/Content View without filters, you'll get all Nodes. You may link in User data (through the author or another field) through Relationships (SQL JOIN bar ON foo.x=bar.y
), but you'll never see all users listed just once or a single row with just a User, since their data is just joined to the Nodes. The same is true for Nodes if you start with a User based View.
Filtering on the same field for more than one content type is useful when your content types are similar or closely structurally related somehow, and are both of the same base type (bundles of say Nodes). This way you can truly list all of these items just by making a Node View and filtering out other bundles, without any joins, so they're both first class items. Then you can get a subset of both types of content by adding a single filter on the [Term reference] field.
However, if the same field is used on Nodes and Users, you'd have to tell Views which instance of that field to filter on by, selecting the Relation to use (if any), ie which table (node or user) to use. (View generates one alias for each table a field is used on automatically, but it can still only compare a filtering value to one of them with one filter, and aliases still use Relationships/JOINs.)
This means you either get a subset based on which Nodes are in a category, or which Nodes were authored by Users that have selected that category.
This is because filters currently (until Views 7.x-3.8) only filter based on a fixed value (using one of several operators), and not the value of another field.
Just to cover a corner case; if you also add another filter, filtering on the same Category value, but using "the other" table as the Relationship (User in a Node View or vice versa) you'll end up only with Nodes in the same category as its author has selected, or only Users which have created Nodes in the category they like. This type of very narrow subset of Users or Nodes would also be generated if you picked any other two fields (one from each of User and Node) to filter on, since the "Content" Field being instances of the same Field settings does not really matter for the result set you'll get back.
Since you want different settings for Term references, create two separate Fields. One for Nodes, allowing two Terms, let's call it "Categories". One for Users allowing one Term, let's call it just "Category".
This will actually make it slightly easier to navigate in the Views UI as you can clearly see which one of the Fields belongs to Nodes or Users later on.
Now, if you're looking to fetch Nodes based on which Category the current User has picked we'll have to figure out exactly what that relationship looks like.
A list of Nodes is not directly relatable to Users, unless the user happens to be the author or there are explicit User/Node reference fields linking them together, so let's break this down in steps.
Start with a Content View, add at least the Title field and the "Content: Categories" field just so we know shat we're getting back from the query. Sort by the Node title or whatever makes sense in your case.
Nodes hold the term ids in our Categories field, but we need the actual Term data, that's one Relationship in the right direction. Add a "Content: Categories" Relationship. Make it Required since we don't want Nodes without Categories set shown. By now your result set will include all Nodes with two Categories set twice, because of the JOIN this created. That's fine.
The Terms are also being referenced by a field on Users, and adding the previous Relationship between Nodes and Terms now allows us to go one step further. Add the "Taxonomy term: User using Category" Relationship and make it required as well. By now the result set will have multiplied the number of times a Node is shown by how many Categories it has, and again by the number of users which have set one of those Terms in their own Category Field. That's also fine.
You can now add a "User: Name" field to see who has chosen the same category used by the Node (note that it's using the Relationship chain).
Now we have established a link from Nodes to Users. Time to limit things to the User we're interested in: the one currently logged in. By now you'll be able to filter the result set based on any User data available through the Relationship chain, including the logged in status. So add a "Current user" filter and set it to "Logged in".
By now, your query is pretty much unreadable, but it works! ;)
In this case we're lucky User can only select one Category, since that prevents multiplying the number of times a Node is shown by the number of matches between the Category and Categories fields. But if you do need User to be able to select multiple categories later, make sure you tell Views to only return unique/distinct matches.
If some of my assumptions are wrong, please comment and I'll update the answer accordingly.