@JasonB, not sure what causes this. It's probably best to use ElementIncidents and ElementMarkers to extract those from the mesh element anyways. Using Position on these is not going to be efficient (will unpack).

Why does FullSimplify not simplify the following expression?

FullSimplify[x == 0 || 1/2 + x/[Pi] [NotElement] Integers]

Since the second disjunct entails the first, why doesn't it simplify it to the second alone?

I mean, the first disjunct entails the second.

Here's a simpler example: FullSimplify[x == 0 || x [Element] Integers]

@user76284 Try FullSimplify[x === 0 || x \[Element] Integers] and 0. == 0

Interesting

Why does that happen?

Is it because x == 0 is not enough to guarantee that x is exactly zero?

@user76284 Right, x == 0 is not enough to guarantee x is an integer, since it could be the approximate zero 0.. Machine numbers are treated as having an uncertainty; from the point of view of a symbolic mathematics program, this is by design. Compare Interval[0.] and Interval[0], for instance. OTOH, == means equal to a certain tolerance (depends on the precision of the numbers and Internal`$EqualTolerance). The symbol x has an unknown precision, so M treats it cautiously.

How can I make it treat all == in an expression as === so it can be simplified with statements about integers?

@user76284 I think my x === 0 above was thoughtless. It evaluates to False immediately because SameQ (===) always evaluates to True or False and x is not the same as 0. Sorry about that.

Reduce[x == 0 && x \[Element] Integers] handles you simpler case, but not the original....

Yeah, conjunction seems to work, but not disjunction.

Replacing || with && successfully reduces it to the stronger condition, namely x==0.