Now, when I use my original code, without the && and the std::forward<>, everything works. I've tested and I can create signals and trigger them with value types, reference types, even const reference types that can be given temporaries as the call parameter. So the original version works and does everything I want.

You have a different case in both examples. As has been explained in your last threads, this uses a special kind of template-deduction, called "universal references",which apply here:

template<typename T> class BlendValue
{
public:
template<typename... Args> BlendValue(Args&&... args) : v(std::forward<Args>(args)...), o(v) { }
};

'This is due to that "Args" is deduced by what you pass to the function.

Now in case of a signal, "args" is part of the class-template-params. When you use Args&&... args, in a function, "Args" are not deduced, so the compiler just makes rvalue references out of it...

template<typename ... Args>
class Signal
{
    void operator(Args&&... args)
    {
    }
}

Signal<bool, int> sig; // Args = bool, int

bool b = true;
int i = 1;
sig(b, i); => sig::operator=()(bool&& bool, int&& int);

Note that even if this would work, you'd probably don't want universal/rvalue references for signal/slots anyways. Since multiple things can respond to the signal there is not use for forwarding (which would mean/could lead to the first receiver of the signal moving the value of one of the attributes away). You'd just want to manually specify what you hand over in the signal:

sig<bool> => operator()(bool)
sig<const std::string&> => operator()(const std::string&)
sig<MyClass*> => operator()(MyClass*)

So then there is no use for "Args&&... args" in the operator, so you can just put "Args... args", because that will have the correct semantic anyways, as you can see above.

;TL;DR: You don't even need perfect forwarding here.