One more thing to consider:
When the functionality is in the regular script unit and this unit is included in the test project, the one gets access to this functionality as soon as he/she opens the project. When the functionality is moved to the script extension, this extension must be deployed to every new workstation that is planned to be used to work with the project that uses this script extension.
My entire framework consists of Script Extensions and a single Script unit (Driver).
For me, anything that is project-agnostic, and/or forms part of the framework (framework should always be project-agnostic), ends up in a Script Extension.
All the Script Extension code is stored in their own version controlled own project.
I take the point that you then need to update any new installs with the extensions, but if you have multiple project suites running common code then your only other option is to have a shared project that they all use. Which doesn't work for me as my office runs several internal networks that can't all see each other so I can't simply reference a single centrally stored project.
Plus, it also sends to be extensions (new functionality), rather than fixes, that get applied to the extensions projects. They have all been in use for several years now and ar every stable. Older projects, which don't use some of the newer functionality in the script extensions, simply don't call them. They didn't exist when the project was created so the project contains no references to them.
If something is subject to frequent change, or is not yet stable, then script script extensions may not be the best idea.
