.libPaths() ordering and immutable site library for staged package rollout

Migrating a small R application package without stopping existing sessions requires a clear library path boundary between the current and candidate package trees.

.libPaths() defines an ordered search list; library() loads from the first tree containing the package. A namespace is loaded once per session, so a running process continues to use the code it loaded. Installing into a shared tree risks new sessions seeing a partially installed package if the first entry is mutated in place.

Permission boundaries add uncertainty. Site libraries are often read-only for application users, while R_LIBS_USER can create a personal library that shadows a project or site tree. Startup configuration may be altered by .Rprofile.

What permission boundary ensures application users cannot write to the site library while a new tree remains discoverable? How should library order be enforced so R_LIBS_USER or .Rprofile does not shadow the intended new tree? Is the first .libPaths() entry expected to be immutable during rollout?