First, note that BFV is traditionally phrased in terms of arithmetic circuits, not boolean ones.
For example, the initial paper has a message space of the form $R_t := \mathbb{Z}_t[x] / (\Phi_n(x))$, where $\Phi_n$ is the $n$th cyclotomic polynomial (when $n$ is a power of two this is simply $x^n+1$).
This is relatively important as the fundamental building blocks of arithmetic circuits is not OR and AND, but (the mod $p$ version of) XOR and AND, which is slightly different.
As for your issues with BFV multiplication, I think that you are misreading the specification of BFV slightly.
Typically (say in the initial paper) the message space is specified as being $R_t$, which as mentioned before is a polynomial ring (when $n$ is a power of 2) $\bmod x^n+1$.
So for our encryption scheme to be fully homomorphic, we need that we can perform the addition and multiplication of the message space on ciphertexts.
This multiplication of the message space is $\bmod x^n+1$ (and $\bmod t$, but whatever), as you have pointed out.
This is to say that arithmetic being $\bmod x^n+1$ is what is mathematically required for the scheme to be fully homomorphic, so the product being of that form is expected, and not a concern.
Of course, application designers may not want to use this "funny arithmetic".
This is something for library designers to solve later though.
For example, one way to "fix" this (which is quite naive --- I am guessing there are better solutions) is to only encode messages into the constant terms of polynomials.
It should be relatively straightforward to see that this "funny multiplication" becomes standard multiplication when restricted to constant polynomials.
There are other things one could do, for example one could allow polynomials of the form $m(x) = m_0+m_1x$ if you know the multiplicative depth of the circuit you're evaluating is at most $\log_2 n$, or more generally $m(x) = \sum_{i =0}^p m_i x^i$ if the multiplicative depth is at most $\log_{1+p} n$.
This is simply because with this depth bound, one cannot produce a polynomial of degree $\geq n$, so the fact that multiplication might "wrap around" doesn't matter.
Of course, I'm sure that there are smarter ideas of what one can do to emulate "standard" arithmetic with the "funny" arithmetic one gets, but that is really orthogonal to understanding BFV.
It's also worth mentioning that your comment
but it needs to be coefficient-wise and on the polynomial, not and for the polynomials itself
sounds like you might be looking for the idea of the canonical embedding.
Specifically, it was noticed roughly a decade ago that if we want an array-like datatype $[a_0,\dots,a_n]$ that one can perform (slot-wise) arithmetic on, then coefficients of polynomials are really a quite bad choice.
This is because (among other things) the natural multiplication operation on polynomials does not lead to multiplication of the underlying coefficients, but convolution of them.
In particular, one has that
$$(a_0+a_1x+a_2x^2)(b_0+b_1x+b_2x^2) = a_0b_0+(a_0b_1+b_0a_1)x + (a_0b_2+a_1b_1+a_2b_0)x^2+(a_1b_2+a_2b_1) x^3+a_2b_2x^4$$
In particular, one doesn't recover the product $a_1b_1$.
One can fix this by (essentially) appealing to a version of the Fourier transform, as a Fourier transform typically can be written as an isomorphism
$$\mathcal{F} : (R, +,\times)\to (R, +,\ast)$$
e.g. it "swaps" convolution with (coefficinent-wise) multiplication.
This is to say that if we instead encode a message in the "canonical embedding" (or equivalently, we encode the "Fourier transform" of the message), then the convolutions will become element-wise multiplication (in our message space).
I don't believe the initial BFV paper does this though, which depending on what you are reading for a specification of BFV may lead to confusion.
But I believe its a relatively common optimization, and should be able to be seen as "just" a different message encoding (there are other benefits to using the canonical embedding such that you would want to reanalyze the protocol in terms of it though).
