Krisztián Szűcs

Apparently we also have a backend test case using a mapping as a single positional argument.

If we allow: ```py t.select([t.foo], t.bar) ``` then should we allow ```py t.select([t.foo], [t.bar]) ``` as well?

My preference would be to either provide args as variadics or as a single list-like argument. Even then we have confusion when to treat list-like inputs as literals vs value...

```py t.select(["a", "b"], ["c", "d"]) # is this two array literals or an error? ``` yes, two array literals, not erroring ```py t.select("a", "b", ["c", "d"]) # is ["c", "d"]...

I would prefer deciding what should be the ideal long term behaviour then extend that to be backward compatible and either raise a deprecation warning or provide a config option...

Another thing I'm not sure about is whether we should do the dereferencing here or not? Like should `t.bind(totally_different_table.col)` raise?

Actually it could help code consolidation. I can try it after the dereferencer improvement gets merged: - #8992

> I'm going to rip out destructure in a separate PR. Updated the test case to expect an input error rather than an integrity error. We should update `unwrap_aliases()` to...

One confusing case: ```py In [4]: table = ibis.table({"a": "int", "b": "string"}) In [5]: table.select(["a", ["b"]]) Out[5]: r0 := UnboundTable: unbound_table_1 a int64 b string Project[r0] a: r0.a ('b',): ['b']...

I think the ideal use case would be to have a well-defined behavior for `ibis => pyarrow` and rely on `pyarrow => pandas` to specify `ibis => pandas` expectations. I...