gcd for fractions works only with reduced fractions. Implementation differs from the description

[alexey-orlov-math]

First of all, the description says: N.B: we define the GCD of $a/b$ and $c/d$ to be gcd$(ad, bc)/bd$, reduced to lowest terms.

While the implementation does essentially $gcd(a,c) / lcm(b,d)$ with lcm being computed like $lcm(d1, d2) = (d1/gcd(d1,d2)) * d2$.
This only works if the fractions are already reduced. For example:

julia> S, x = polynomial_ring(QQ, "x");

julia> F = fraction_field(S);

julia> gcd( F((x+1)*(x+2), (x+2)^2), F((x+1)^3, (x+1)*(x+2)) )
(x + 1)//(x^3 + 5*x^2 + 8*x + 4)

julia> gcd( (x+1)*(x+2) //  (x+2)^2 , (x+1)^3 // ((x+1)*(x+2)) )
(x + 1)//(x + 2)

EDIT: note that the algorithm described in the comment would work

[fieker]

legal fractions in AA are always in lowest terms. This is not always the best convention, but the system is built around it.

[alexey-orlov-math]

legal fractions in AA are always in lowest terms.

this is fair, but the "constructor"
function (a::FracField{T})(b::T, c::T; reduce::Bool = false) where {T <: RingElem}
and others do not reduce by default. I did notice the pattern of having "check" options in Hecke for example and allowing "non-legal" objects to be created, but (ok, this is programmer in me speaking)

1. What should happen with "illegal" objects when doing basic operations? should we check? should we try to make it work? Because currently (with my limited insight into the codebase) it is "random things might work" which is a bit shaky
2. We create non-reduced fractions by default (with constructor), which is kinda bad default (and opposing to Hecke demanding explicit opt-out of checking)

Anyway, this is just something i have found why looking into unrelated things, this can be closed if this is "by design"

[fieker]

as far as I can tell: operations on illegal input can do whatever they want. To put it into perspective: always checking everything everywhere is too expensive. The convention is/ was/ should be to verify correctness on the top level where the user interaction is. Once data made it into the system, it is supposed to be legal and correct, so the code is allowed to or even expected to cut corners. Of course, if there are trivial ways (relative to the problem) to check we're using assertions to do so. For more expensive invariants, @hassert can be enabled (for testing, debugging).
On top level, we generically allow check to bypass expensive checks - but the consequences are on you.
The fraction field, I assume got confused, so its good that you saw this. Rings are not always euclidean, so "simplified and lowest terms" do not work. I assume the author of the gcd then implicitly thought of euclidean rings - and unique fractions