It looks like some of the issues were already addressed:

# 2873a731 == nixpkgs-unstable at the time of writing

echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#lua
# ./share/lua/5.2/?.lua;./?.lua;./?/init.lua
echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#lua5_1
# ./share/lua/5.2/?.lua;./?.lua;./?/init.lua
echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#lua5_2
# ./share/lua/5.2/?.lua;./?.lua;./?/init.lua
echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#lua5_3
# ./share/lua/5.2/?.lua;./?.lua;./?/init.lua
echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#lua5_4
# ./share/lua/5.2/?.lua;./?.lua;./?/init.lua
echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#luajit
# ./share/lua/5.2/?.lua;./?.lua;./?/init.lua
echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#luajit_2_0
# ./share/lua/5.2/?.lua;./?.lua;./?/init.lua
echo "print(package.path)" | nix run github:NixOS/nixpkgs/2873a731#luajit_2_1

I encountered the issue like this (fennel is a lisp-like that compiles to lua and it's distributed as a lua package; running it you'd assume to be able to load lua packages like you normally would):

# nix run github:NixOS/nixpkgs/2873a731#lua.pkgs.fennel -- -e '(. package :path)'
# formatted for clarity:
/nix/store/psx2jaqhvnizbn6sraapdc8afl2d77xv-fennel-luarocks-config.lua/share/lua/5.2/?.lua
/nix/store/psx2jaqhvnizbn6sraapdc8afl2d77xv-fennel-luarocks-config.lua/share/lua/5.2/?/init.lua
/nix/store/nb3wjqhykfd6f3pds9smxdr1xfc4pwaw-luarocks-3.9.1/share/lua/5.2/?.lua
/nix/store/nb3wjqhykfd6f3pds9smxdr1xfc4pwaw-luarocks-3.9.1/share/lua/5.2/?/init.lua
/nix/store/3dgc655m12q6x1prf8jp1386vwgwgv2c-lua5.2-fennel-1.3.1-1/share/lua/5.2/?.lua
/nix/store/3dgc655m12q6x1prf8jp1386vwgwgv2c-lua5.2-fennel-1.3.1-1/share/lua/5.2/?/init.lua
/home/arne/.luarocks/share/lua/5.2/?.lua
/home/arne/.luarocks/share/lua/5.2/?/init.lua

My LUA_PATH and LUA_CPATH are empty, so this is the default behavior. This is the result of the above command after my patch:

/nix/store/a5a7d7l9ckqw63h80zhjpx8i671gappv-fennel-luarocks-config.lua/share/lua/5.2/?.lua
/nix/store/a5a7d7l9ckqw63h80zhjpx8i671gappv-fennel-luarocks-config.lua/share/lua/5.2/?/init.lua
/nix/store/d97swj4m7mhq64wmix69bk5vn9kjdakl-luarocks-3.9.1/share/lua/5.2/?.lua
/nix/store/d97swj4m7mhq64wmix69bk5vn9kjdakl-luarocks-3.9.1/share/lua/5.2/?/init.lua
./?.lua
./?/init.lua
/nix/store/6m9qq5k0sn0sm5fixy1lbbc0hik3lxl7-lua5.2-fennel-1.3.1-1/share/lua/5.2/?.lua
/nix/store/6m9qq5k0sn0sm5fixy1lbbc0hik3lxl7-lua5.2-fennel-1.3.1-1/share/lua/5.2/?/init.lua
/home/arne/.luarocks/share/lua/5.2/?.lua
/home/arne/.luarocks/share/lua/5.2/?/init.lua

@teto i saw you in a couple of lua issues. can you provide some feedback over whether this is useful at all, or is this misguided? see #273342 (comment) for a closer description of what's happening.

sry for the delay. First of all thanks for trying to address the issue ! Happy to see folks trying to improve the lua ecosystem.

What I would like to see is a test in pkgs/development/interpreters/lua-5/tests/default.nix to check for the behavior you want (even as a separate PR).

I dont know how involved you want to be but to limit the issues mentioned at #189689 I think it would be great to have luajit be expressed as an overrideAttrs of the default lua interpreter maybe ? that would limit the drift between the 2 and might help with solving the issue.
pkgs/development/interpreters/lua-5/interpreter.nix
pkgs/development/interpreters/luajit/default.nix

At one point I decided to patch the lua interpreter to change the default LUA_PATH. Patching upstream software might not have been the correct call and might have created your issue. Not sure if I want to rollback this yet, or make it configurable.

@teto thanks for your feedback! i added some tests locally. can you help me figure out how to run them so i don't have to do the git-push-wait-for-ci-to-fail-git-commit-ammend-force-push-dance?

diff --git a/pkgs/development/interpreters/lua-5/tests/assert.sh b/pkgs/development/interpreters/lua-5/tests/assert.sh
index fe5582a0b062..328c4ee7f93a 100644
--- a/pkgs/development/interpreters/lua-5/tests/assert.sh
+++ b/pkgs/development/interpreters/lua-5/tests/assert.sh
@@ -14,3 +14,9 @@ function assertStringEqual {
         fail "Strings differ"
     fi
 }
+
+function assertStringContains {
+    if ! echo "$1" | grep -q "$2" ; then
+        fail "String does not match"
+    fi
+}
diff --git a/pkgs/development/interpreters/lua-5/tests/default.nix b/pkgs/development/interpreters/lua-5/tests/default.nix
index 38479af5f207..02b9e124f0d1 100644
--- a/pkgs/development/interpreters/lua-5/tests/default.nix
+++ b/pkgs/development/interpreters/lua-5/tests/default.nix
@@ -27,6 +27,10 @@ let
         wrapLuaPrograms
       '';
     });
+
+    luaWithModule = lua.withPackages(ps: [
+      ps.lua-cjson
+    ]);
 in
   pkgs.recurseIntoAttrs ({
 
@@ -40,11 +44,22 @@ in
       '';
   };
 
-  checkWrapping = pkgs.runCommandLocal "test-${lua.name}" ({
+  checkWrapping = pkgs.runCommandLocal "test-${lua.name}-wrapping" ({
     }) (''
       grep -- 'LUA_PATH=' ${wrappedHello}/bin/hello
       touch $out
     '');
 
+  checkRelativeImports = pkgs.runCommandLocal "test-${lua.name}-import" ({
+    }) (''
+      lua_vanilla_package_path=$(${lua}/bin/lua -e "print(package.path)")
+      lua_with_module_package_path=$(${luaWithModule}/bin/lua -e "print(package.path)")
+
+      assertStringContains "$lua_vanilla_package_path" "./?.lua"
+      assertStringContains "$lua_vanilla_package_path" "./?/init.lua"
+
+      assertStringContains "$lua_with_module_package_path" "./?.lua"
+      assertStringContains "$lua_with_module_package_path" "./?/init.lua"
+    '');
 })

I'm afraid I'm not deep enough into either lua or nix packaging to unify the lua / luajit packages as you described

All good, figured it out! From the base directory of this repo I was able to run the test like this:

nix build .#lua.tests.checkRelativeImports 

At one point I decided to patch the lua interpreter to change the default LUA_PATH. Patching upstream software might not have been the correct call and might have created your issue. Not sure if I want to rollback this yet, or make it configurable.

I removed the patch and hopefully simplified the way LUA_PATH / LUA_CPATH is configured in the process. This means the path can be configured by overriding LuaPathSearchPaths / LuaCPathSearchPaths if I didn't do anything silly.

This also fixed a failing test, tested via nix-build -A pkgs.lua.passthru.tests.

Do you mind if I merge your code in new PRs ?
I would like to merge your changes to tests first, and then fix up things differently.
If I run from ubuntu

lua -e "print(package.path)"  
./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua;/usr/share/lua/5.1/?.lua;/usr/share/lua/5.1/?/init.lua

so we are just missing ?.lua from default LUA_PATH.

I don't mind at all! I just ran your command on CentOS 7 and it looks like you're right. Only ./?.lua is missing by default,

i've stumbled across this again, and while it seems like lua is fixed, luajit most certainly is not.

i belive i found the underlying bug that stops this from working, it can affect both luajit and lua5.

@heyarne sry it took so long but this should be fine on master. Thanks to your contributions and @lolbinarycat we now have some more tests