unpack does not guarantee sequence
actually, it does, as virtually all objects in Pd, from right to left (trigger is no exception).
So you're able to do what you want if you stack [pack] and [unpack] together!
I saw the post on FB about why [t 10 66 -100 3000] doesn't work as expected.
It wasn't expected to work at all in Vanilla, the help file shows how you shouldn't use floats at all as arguments. It might be an expectation if you're using that feature in Purr Data, but then, I think the expectation flaw is that Purr Data has different behaviour for Vanilla objects that break compatibility.
That seems like a reasonable expectation based on how [pack 10 66 -100 3000] works
Also giving a list to [t f f f f] seems like it should work like [pack f f f f].
It should definitely not as the trigger object has nothing to do with pack or any other object. Pd objects work within their own design paradigms. Having a simple look at trigger's help file shows you that a list to [t f f f f] will convert the list to a float and trigger it. And the facebook post doesn't even request for this feature, it was something to do with how trigger works in Max and in Purr Data, not a request that it should behave like [pack].
I am just saying that such irregularities and special cases in a language given similar syntax (as with English!) make it more difficult to learn, use, and master.
I don't see it as a "syntax" matter. Every object has a set of arguments and flags. Some take floats, some take symbols, etc... it's all based on what the task of the object is. If you do not seem to understand the purpose and function of [trigger], then it might be confusing. As Iohannes pointed out, [trigger] has a very clear method for handling lists and it should not be changed because of any other object in Pd.
By the way, [pack] does not have a list method, it behaves much like every object in Pd that has no list method and many inlets, it just splits the message into the inlets. Trigger only has one inlet, it's a completely different case without any syntactical conflict.
I think given present behavior, [t 35] should throw an error to the console.
or a mention in the help file that floats will just work as "float".
But I would prefer the change requested.
cheers