back_inserter for several container arguments
The general structure seems fine to me. However, some things can still be improved!
Iterator requirements
Iterators are required to satisfy the Swappable and CopyAssignable named requirements, but the current implementation doesn't. (This is also why the std::back_inserter implementation you looked at used pointers instead of references, the latter cannot be reseated.)
And from a design perspective, this provides an interesting dilemma: Do you want to support assignment from different underlying container types? For example, like this:
std::deque&lt;int&gt; copy1{};
std::list&lt;int&gt; copy2{};

auto out = stx::back_inserter(copy1, copy2);
// out is of type stx::back_inserter_iterator&lt;std::deque&lt;int&gt;, std::list&lt;int&gt;&gt;

std::vector&lt;int&gt; copy3{};

out = stx::back_inserter(copy2, copy3, copy1);
// assignment from stx::back_inserter_iterator&lt;std::list&lt;int&gt;, std::vector&lt;int&gt;, std::deque&lt;int&gt;&gt;

If no, the solution is easy: Change the container references to pointers (to make assignment possible), add assignment operator overloads, and either use std::swaps default implementation or write your own swap function for stx::back_inserter_iterator.

This is the easy way, but in reality likely not very useful, since assignment only allows for the exact same container types.

If yes, the solution becomes more complicated, as the actual container types need to be abstracted away. One idea for this is using inheritance in an external storage class (rough idea):
template&lt;typename ValueType&gt;
class container_storage_base {
public:
    virtual ~container_storage_base() {}
    virtual void push_back(const ValueType&amp;) = 0;
    virtual void push_back(ValueType&amp;&amp;) = 0;
};

template&lt;typename Container, typename... Containers&gt;
class container_storage : container_storage_base&lt;typename Container::value_type&gt; {
    std::tuple&lt;Container&amp;, Containers&amp;...&gt; containers; // can use references here

public:
    void push_back(const typename Container::value_type&amp; value) override { ... }
    void push_back(typename Container::value_type&amp;&amp; value) override { ... }
};

Inside of stx::back_inserter_iterator, you could then simply store a std::shared_ptr&lt;container_storage_base&lt;ValueType&gt;&gt;, thus freely allowing assignment between different stx::back_inserter_iterator&lt;ValueType&gt; instances (as long as ValueType remains the same).

Why std::shared_ptr?
We need some indirection in order to allow for virtual dispatch to work, and using a pointer seems to be the easiest solution for that. However, we also need to release the container_storage object once we no longer need it, and for that, smart pointer come in very handy.
But: Iterators need to be copyable, and that isn't something supported by std::unique_ptr (only allowing for a unique owner), thus std::shared_ptr was chosen.

Other Nitpicks

Most functions could be marked noexcept (even if only conditionally).

Q &amp; A



does the operator= method with the r-value work as intended or do I need to pass the value differently to the lambda?

Works as intended.
Well, mostly. With the expansion, value will be moved from for every container, i.e. every container but the first will move from an already moved-from value. To get the initial value to all containers, copies will need to be made.



do I need an extra static_assert to check that each Container supports the same value_type or at least some that are convertible to avoid overloading the user with template errors in case they are different?

Do you need to? Not necessarily.
Would it be nice for users of the implementation? Absolutely!



is there another solution where I could let the user provide and optional argument for execution policy, for example std::execution::par

I'm confused: Execution policies are for algorithms, not iterators themselves.
Of course, you can always add a data member to store a value if you want to, but I fail to see how storing an execution policy would be helpful here, as there aren't any calls to algorithms internally (and just adding an execution policy to data doesn't accomplish anything).



the original std::back_inserter saves the container as pointer - is there any advantage versus my inserter which saves them per reference?

See above, you cannot reassign references.