traverse_get Changes Behavior Based On Using sol::optional

[atom0s]

sol version: AshitaXI@d4b13ff (Also tested with develop.)
Lua version: MoonJit via AshitaXI/moonjit@094d971
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:

sol2/tests/run_time/source/tables.insertion.cpp

Line 141 in 7aae1aa

TEST_CASE("tables/get create_if_nil", "create tables all the way down") {

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.