For lifecycles, BEAM calls your NIF's load/upgrade/unload hooks as appropriate.
For global NIF module data, you're steered towards setting it up in the priv_data pointer passed to those hooks, and retreivable with enif_priv_data, but you can also use static variables or whatever else (it is native code, BEAM can't force you to do anything).
Lifecycle of Erlang Terms is bound to environments, often NIFs get Erlang Terms from the process that called them, and return Erlang Terms to that process... You can't keep references to those in native variables beyond the scope of the function call though; if you need to keep things around, you've got to either copy the values directly into native values, or use erl_make_copy to copy to an environment that you manage. (The erl_nif manpage is probably more clear than me, look for ErlNifEnv)
All that said, I think you're looking for a multi-table atomic rename like in MySQL[1]; so that you can replace a table in a single transaction? If that's all you want to change, you probably should just modify ets, rather than reimplement all the things; I'd be somewhat concerned about adding additional locking, but I don't know what the existing locking looks like.
For global NIF module data, you're steered towards setting it up in the priv_data pointer passed to those hooks, and retreivable with enif_priv_data, but you can also use static variables or whatever else (it is native code, BEAM can't force you to do anything).
Lifecycle of Erlang Terms is bound to environments, often NIFs get Erlang Terms from the process that called them, and return Erlang Terms to that process... You can't keep references to those in native variables beyond the scope of the function call though; if you need to keep things around, you've got to either copy the values directly into native values, or use erl_make_copy to copy to an environment that you manage. (The erl_nif manpage is probably more clear than me, look for ErlNifEnv)
All that said, I think you're looking for a multi-table atomic rename like in MySQL[1]; so that you can replace a table in a single transaction? If that's all you want to change, you probably should just modify ets, rather than reimplement all the things; I'd be somewhat concerned about adding additional locking, but I don't know what the existing locking looks like.
[1] https://dev.mysql.com/doc/refman/8.0/en/rename-table.html