Посмотрите на скрипт wscmd. Когда-то я его уже представлял здесь, но сделал это неубедительно. Сейчас этой темы уже нет, возможно она лежит в offline-архиве. По сути - это смешанный двуязычный скрипт, который генерирует временный WSF-файл в текущем каталоге, автоматически подключает все следующие файлы из каталога, который находится рядом со скриптом wscmd и запускает результирующий WSF-файл. По окончании выполнения временный файл удаляется.

Пример.
Пусть Ваши файлы лежат в следующем порядке

Если путь к wscmd.bat прописан в переменной %PATH% то Вы можете запустить скрипт так:

Посмотрите, возможно это близко к Вашим запросам. А мне будет интересно получить отзыв о его работе. Скрипт обладает еще большими возможностями. Почитать на корявом английском можно здесь http://code.google.com/p/jsxt/wiki/wscmd.

я хотел бы имея допустим D:\\scripts\\Network.js, которому для исполнения своего кода необходимы сущности(объекты, классы, функции) объявленные в D:\\scripts\\Utils\\UniUtils.js подключить к D:\\project.js,

Я понял Вас так. Для простоты объяснения я сокращу имена скриптов до абстрактных. Есть два зависимых скрипта A.js и B.js. Надо использовать сущности скрипта A.js в проекте C.wsf. Если эти скрипты суть только объявления зависимых сущностей и не выполняют никаких других действий, кроме объявления, то порядок подключения неважен.

Пример:

A.js

function A()
{
    WScript.Echo('A() before');
    B();
    WScript.Echo('A() after');
};

.
B.js

function B()
{
    WScript.Echo('B()');
};

.
C.wsf

<?xml version="1.0" encoding="utf-8" ?>

<package>
<job id="wscmd">
<?job error="false" debug="false" ?>
<script language="javascript" src=".\A.js"></script>
<script language="javascript" src=".\B.js"></script>
<script language="javascript"><![CDATA[

WScript.Echo('main()');
A();
B();
WScript.Echo('main() again');

]]></script>
</job>
</package>

.
Результат

.
Видно, что модуль A.js зависит от B.js, но его "объявление" раньше модуля B.js. Более того. Можно было бы описать некую функцию, в основном скрипте C.wsf и заменить все вызовы WScript.Echo на вызов этой функции и это тоже работало бы.

function alert(msg)
{
    WScript.Echo(msg);
};

.
Другое дело, если в файле A.js за пределами объявленных сущностей модуля выполняются некоторые действия с сущностями из модуля B.js. Тогда порядок важен. Возможно имеет смысл переписать файл A.js, так чтобы сохранить модульную зависимость от B.js, но действия выполнялись за пределами файла A.js.

Не совсем, я хотел бы имея допустим D:\\scripts\\Network.js, которому для исполнения своего кода необходимы сущности(объекты, классы, функции) объявленные в D:\\scripts\\Utils\\UniUtils.js подключить к D:\\project.js,
т.е. объвив в коде  Network.js

include(\\Utils\\UniUtils.js)

а в коде project.js

include(\\scripts\\Network.js)

и все необходимые скрипты подключались бы каскадом.

Вы работаете над разработкой некоторого скрипта, назовем его project.js. И У Вас есть набор библиотек (Ваших, найденных в сети, написанных на js или vbs, неважно), которые используются в Вашем проекте. Верно ли, что Вы не хотели бы думать о том, какие библиотеки из имеющихся у Вас могут понадобиться в данный момент, но Вы хотели бы чтобы они все были доступны на момент разработки и Вы не думали бы - какие скрипты уже подключены к project.js?

PS:Да, в сторону *.hta , *.htm я уже думал, и даже попробовал... но это опять же решает проблему отчасти:
ну да - я могу подключить скрипты... я даже в этих скриптах через eval(fso.OpenTextFile(foo).ReadAll() и абсолютные пути могу подключать другие скрипты.
относительные пути никак не получается использовать, так как eval будет отрабатывать в контексте это hta/htm , и соответственно все относительные пути будут отстоять от него, а не от подключаемых скриптов.

PPS: Есть правда интересные "костыли" - возможно реализовать некую функцию function include(){...} таким образом, чтобы при исполнении она включала в исполняемый код переменную с абсолютным путем подключаемого скрипта, как уже подсказывали который легко вычисляется (даже если используем символические), ну и собственно обвесить все скрипты которые хотелось бы подключать этой нашей чудо функцией...
но это сравни изобретению велосипеда, изначально не хотелось этого делать... хотя

PPPS: По поводу WSF - все очень круто (мне так сначала показалось), мало того что через тег <script> можно подключать скрипты, так и на разных языках ( очень прельщала перспектива не переводить кучи готового VBScript-кода в JScript потому как я от VB-образных языков ухожу в уныние чуть менее чем полностью.)
Но таки я не нашел как можно WSF подключить к WSF, сколько я понимаю Microsoft предлагает захерачить один такой огромный WSF с кучей <job>-ов внутри.
ну я как-бэ за модульность кода - мне такой подход не по душе

каскадировать библиотеки (подключать скрипты которые в свою очередь сами что либо подключают

Ни *.wsf, ни *.hta не позволяют что-то там каскадировать…

Всем доброго времени суток...
Имеем *.wsc (Windows Script Component) - насколько я понял, это единственный способ при работе с WSH, хотя бы как-то, худо бедно, но каскадировать библиотеки (подключать скрипты которые в свою очередь сами что либо подключают, как правило скрипты с часто используемым кодом, представленного в виде экспортируемых функций/методов)

Если не столь важно работать именно с WSH, то, используя "оболочку" для скриптов в виде HTA-приложения, модули со своими частоиспользуемыми функциями на этапе старта HTA также можно подгружать, указав "src=" в теге "<script>". Например:

<!-- Including_user_function_(VBscript's)  -->
<script language=VBScript src="udf_module_1.vbs"></script>

<!-- Including_user_function_(Jscript's)  -->
<script language=javascript src="udf_module_2.js"></script>

ps."asp" выбран ради подсветки:)

Как видите - только полные путь и имя. Вы можете вычислить полный путь относительно запущенного скрипта:

var dirname = WScript.ScriptFullName.replace(/[^\\]+$/, '');

var objWSC = GetObject ("script:" + dirname + "TestCOM.wsc")

<?xml version="1.0" encoding="windows-1251" standalone="yes"?>
<?component error="true" debug="true"?>
<component>
<registration progid="TestCOM"/>
<public>
    <property name="ScriptingHost" internalName="WScript"/>
    <method name="ShowMSG"/>
</public>
<script language="JScript"><![CDATA[
   function ShowMSG(SomeString){
        WScript.Echo(SomeString)
   };
]]></script>
</component>

Ну и собственно js-скрипт который таки вышеупомянутый wsc использует
Например: D:\SandBox\ScriptDir\wscConnected.js

var objWSC = GetObject ("script:D:\\SandBox\\ScriptDir\\wcs\\TestCOM.wsc")
objWSC.ScriptingHost = WScript
objWSC.ShowMSG('Hello from TestCOM.wsc !')

Так, вот мой вопрос к коллективному разуму, заключается в следующем:
Можно ли при обращении к объекту из скрипта как либо использовать относительный путь?
применимо к данной ситуации что-то вроде::

var objWSC = GetObject ("script:wsc\\TestCOM.wsc")