It depends on the type of the OTP method and implementation details. Whereas [RFC4226] (the counter based OTP) can be understood to forbid reuse, as it says:
the server's counter value is only incremented after a successful HOTP
But that may not be a guarantee that there is no time window that the same HOTP token will be usable - multithreaded authentication servers, with concurrent database access may overlook this detail.
It is also describing that:
RP3 - P SHOULD be implemented over a secure channel in order to protect users' privacy and avoid replay attacks.
Which implies they don't consider it the property of the protocol to protect against reused tokens!
Similarly, for time based OTP [RFC6238] explains that it's a good protection against attacks to reduce the time window when a token is valid. But it is mentioning the token is consumed, which, to some may imply it cannot be consumed again.
First, a larger time-step size exposes a larger window to attack. When an OTP is generated and exposed to a third party before it is consumed, the third party can consume the OTP within the time-step window.
I, personally do not think a copied second factor should be valid, but this is not necessarily what the standards say, so there may be variations on how this is interpreted. Other 2FA vendors may not even adhere to any of the standards, and may have stricter or looser requirements. Let me also note that it may be difficult to implement a reliable method of locking out all but the first use of a token within widely distributed networks, for all cases.
Update: now that I think of it, I can see two additional ways of preventing access with duplicate OTPs - one is at the preparation: making sure there's only password login out there that is in progress of accepting an OTP until the authentication timeout. The other is invalidating the already granted session, in addition to the duplicate one. This can be easy in a web-based service, but not as convenient with a computer shell access.
Also to be considered that you can't be sure the valid user is the first one, so it can be a hindrance for the them as well. In the case of true MITM, the attacker can even stop the genuine attempts by them so that there can't even be a notification over the same channel.
As you can see, it's not as simple of accepting or not accepting the duplicate OTP - you need to consider the user of the service, how they can get into this situation and how they will be the least harmed, or best served. Perhaps this is why the standards won't discuss these details, and leave it up to you.
: https://tools.ietf.org/html/rfc4226 RFC4226-HOTP
: https://tools.ietf.org/html/rfc6238 RFC6238-TOTP