traverse_get Changes Behavior Based On Using sol::optional

[atom0s]

sol version: https://github.com/AshitaXI/sol2/commit/d4b13ff864c94b0154ec89b2b7332152babbaac4 (Also tested with develop.) Lua version: MoonJit via https://github.com/AshitaXI/moonjit/commit/094d971c0a9f76025e2c61fab65969aea7fdb753 Compiler version: VS2022 17.0.1 (Using C++20 /std:c++latest)

Issue Description:

While using traverse_get, sol does not honor 'deep'/'named' tables if you do not use it with 'sol::optional'. By this, I mean the following:

// Example 1
auto test = lua.traverse_get<sol::table>(sol::create_if_nil, "t1", "t2", "t3");

print(type(t1.t2.t3)); -- This will error: 'attempt to index global 't1' (a nil value)'

// Example 2
auto test = lua.traverse_get<sol::optional<sol::table>>(sol::create_if_nil, "t1", "t2", "t3");

print(type(t1.t2.t3)); -- This will print 'table'.

In Example 1 sol will create the table locally, but it is not named. There is no instance of t1 in the global state, and thus, not accessible.

In Example 2 sol will create the table globally (named) and be accessible.

The docs in regards to this do not state that this is the expected behavior though, so I'm not sure if this is expected or potentially a bug. This also doesn't seem to follow what should be happening if written in the flattened format of:

// Test 1 - This breaks the Lua state altogether it seems. Print no longer functions from Lua directly.
auto test = lua[sol::create_if_nil]["t1"]["t2"]["t3"];

// Test 2 - This breaks the Lua state altogether it seems. Print no longer functions from Lua directly.
auto test = lua[sol::create_if_nil]["t1"]["t2"]["t3"].get_or<sol::table>();

I do see there are tests for this stuff but I'm unable to run them in my current environment: https://github.com/ThePhD/sol2/blob/7aae1aaaaa1bbcc03fd059fe38075cfe3f4b2e90/tests/run_time/source/tables.insertion.cpp#L141

I'm not able to get the test stuff running though. Doesn't seem like CMAKE wants to honor any setting I give it.

Edit: Small edit, forgot to mention this is easily worked around so these aren't blocking/breaking issues, just stuff I noticed while trying things with the API today that seemed like they should work.