Iter 1: Reusable, robust c++ std::hash for GMP's big integer type
Answers to your questions

In MurmurHash3_size_t(), I check SIZE_MAX to tell whether I'm on a 32 bit system or a 64 bit system. Does this check make sense, are there alternatives which are better?

I think it's not worth it to write a generic version of this that avoids checking SIZE_MAX, even though that is possible. Machines with a different size_t size than 32 or 64 bits are uncommon, unless you're talking about 8 and 16 bit machines, but I'm assuming you are not interested in using bigints on those.
But don't forget to #include &lt;cstdint&gt;, otherwise SIZE_MAX might not be defined! Alternatively, use sizeof(size_t) == 4 and == 8, in combination with if constexpr (...) instead of #if ....

Near the end of the file hash_mpz.cpp, I have the statement return hash&lt;mpz_srcptr&gt; { }(x.get_mpz_t());. Does this create an object of type hash&lt;mpz_srcptr&gt; for every calculated hash value?

Technically, yet. But those objects don't have any member variables, just a member function operator(), which is resolved at compile-time, so there is no need to worry about inefficiencies here.

I'm not sure whether I'm using the references const mpz_class &amp;x and const mpz_t &amp;x in the most efficient way. This is partly due to GMP being a C library, mpz_t is a 1 element array with element type __mpz_struct and mpz_class being something rather obscure to me.

Using const references to the objects is perfectly fine.

Last but not least, do you see anything else which can be improved?

Yes, see below.
Your functions don't handle negative bigints correctly
As it mentions in the excerpt from gmp.h you posted, _mp_size will be negative for negative bigints. You need to handle this. One way would just be to write:
return MurmurHash3_size_t(..., abs(x-&gt;_mp_size) * sizeof(mp_limb_t), ...);

However, this means that for a given positive number, that number and its negative will get the same hash value. It may or may not be an issue for your application. One possible solution is to use a different seed value for negative numbers.
Consider using std::hash to calculate the hash
Yes, you can use std::hash instead of implementing your own. Of course, you need to pick an appropriate existing specialization std::hash. You could iterate over the limbs in the bignum, which are either 32 or 64 bit integers, so you could std::hash those individually, but then the questions is how to combine them. Just adding or XORing them might not result in a good final hash value if there are any patterns in the input. But in C++17, there is a specialization of std::hash for std::string_view. So you can create a view for the limb array, and hash that:
size_t hash&lt;mpz_srcptr&gt;::operator()(const mpz_srcptr x) const {
    std::string_view view{reinterpret_cast&lt;char *&gt;(x-&gt;_mp_d), abs(x-&gt;_mp_size) * sizeof(mp_limb_t)};
    return std::hash&lt;std::string_view&gt;{}(view);
}

There is a good chance that the standard library's hash function for strings is a variant of MurmurHash, see for example this question.
Use the appropriate cast operator instead of C-style casts
You should use static_cast&lt;&gt;() if possible to cast similar types, so the compiler will be able to generate an error if you are doing incorrect casts. For example:
size_t hash&lt;mpz_t&gt;::operator()(const mpz_t x) const {
    return hash&lt;mpz_srcptr&gt;{}(static_cast&lt;mpz_srcptr&gt;(x));
}