If you use a different Mathematica kernel to run "Notebook B", then the state of the current kernel will not be affected.
First, consider these questions:
Do you really need a notebook? Can't you just put the code in a plain text file (an
If you do need a notebook, do you really need to display it? Or is it sufficient to just run it?
The simplest way to run a script (plain text file with code) is to invoke the second kernel as you would invoke any other process:
Run["math -script myscript.m"]. You will need to use the full path to and correct name of the kernel executable. There will be no interaction between your current kernel and the subsidiary kernel.
If you really need to run a notebook, evaluate
NotebookEvaluate in the subsidiary kernel. It can take a file name. A command line like the following should work, but I haven't tested it:
math -run 'NotebookEvaluate["book.nb"]; Quit'
Do check the
InsertResults option of
If you also want to display that notebook, then things get much more messy. I don't want to go into this unless you make your question more specific, because there are many things which may or may not go wrong, depending on what specific things you are doing and what is contained in your notebook. In principle you could
NotebookOpen the notebook, set up a new evaluator in the kernel configuration option, set the evaluator of the notebook to that new kernel, then evaluate the notebook. But it's not robust. What if your notebook has dynamic elements? They may auto-evaluate upon opening.
It is also possible, in principle, to control the subsidiary kernel through MathLink. I have done this, precisely with the goal to evaluate notebooks in a separate environment (although I did not need to display them). While I now have a setup that works for my specific use case, I hit some problems and some version-dependent bugs on the way, so I don't recommend this approach unless you know that you need it and you are prepared to spend a lot of time.