Hello all, The LaTeX team have recently taken steps to extend the LaTeX2e kernel to provide some low-level support for post-TeX90 engines. This has included integrating parts of the functionality of the etex package and various ad hoc additions to the format-building process. These changes were released in time for TeX Live 2015 and have largely gone smoothly (the team are working to deal with outstanding issues/grey areas and expect those to be sorted shortly). For LuaTeX there are other new register types that need allocation but that has not to date been covered at all by any pre-built formats. As well as registers, there is also a need to manage some functionality at the Lua level, principally addition to callbacks, which shares certain key characteristics with register allocation. Most notably, all of these require *exactly one* implementation is active. To date, support for this area has been left to package authors, with both the "luatex" and "luatexbase" packages available. This situation has led to some issues and also means that many basic uses of LuaTeX with LaTeX have to pull in quite a bit of material. Following on from the introduction of 'engine awareness' in the 2015/01/01 kernel release, the team are now examining how this LuaTeX situation can be better addressed. Following some initial consultation with the authors of luatex and luatebase, we have therefore drafted an approach to the area as the basis for discussion. The code we have at present is available from https://github.com/josephwright/ltluatex This consists of two parts: code to be added to the kernel (in ltluatex.dtx) and code to be made available as a separate package (in lualatexsupport.dtx). Between the two parts we cover the majority of the functionality of luatexbase. We are looking for feedback in two areas. Firstly, does the functionality provided cover the needs of package authors using LuaTeX? Secondly, we would like input on how a transition to new support code can be managed. We are reluctant to suggest a complex compatibility layer for either our code or the existing packages, and suspect at this stage that a clean 'step change' may be needed for packages working with LuaTeX. However, this is a complex area and needs careful consideration. All input most welcome. -- Joseph Wright