Projekt OUX zaprezentowany niegdyś w postaci implementacji prototypowej ‟tracon” nie zawierał jeszcze implementacji całej definicji, która była opisywana podczas jej wymyślania pod nazwą opRWTng. Z tej teorii OUX nie zawierał implementacji ‹zdarzeń› obiektów, ponieważ nie wiadomo było, jak je obsługiwać w obecnym języku i kompilatorze C kompilującym programy do standardowego systemu ‘unix’ (pseudo‐POSIX). Obecnie definicja nazw używanych w projekcie uległa formalnej zmianie (przez formalne odrzucenie nie wyliczanych nazw opRWTng dla nazw wybranych ponownie do urzeczywistnionej definicji) oraz projekt implementacji (mimo jeszcze niezaimplementowania fizycznego w prototypie, co nastąpi w czasie dostępnym względem innych priorytetów) został uzupełniony do pełnej definicji opisanej teoretycznie pod nazwą opRWTng. Nazwy z bieżącego akapitu zostały w ich użytym znaczeniu porzucone już dawno lub znikoma ilość być może niedawno, a jeśli występują tak samo brzmiące wyrazy w obecnej całościowej definicji OUX, to nie mają one związku formalnego z projektem opRWTng. W szczególności “zdarzenie obiektu” nie ma bytu w OUX, mimo że jest obecne pojęcie konkretne: ‹zdarzenie›, które odnosi się do obiektu przepływu danych ‹menedżera› — i nie ma innych ‹zdarzeń›. Definicja opRWTng przestała być projektem, a stała się historią, i nie utrzymuje już samoistnie żadnej nazwy, a utrzymuje je definicja OUX, mimo że niekoniecznie przejęła ona już w swoim projekcie wszystkie rozwiązania szczegółowe określone w opRWTng spośród tych, które są właściwe dla niej. Projekt OUX posiada jeszcze własną nazwę OUX, która oczywiście pochodzi z DQUXGdzie zamiast symbolu “D” wcześniej był używany symbol litery ‛O’. Zmieniony z oczywistych względów podobieństwa do cyfry ‛0’ i niepotrzebnego związku graficznego z używanym ‛Q’. czyli z symboli bloków wykonywalnych języka programowania ‘natywnego’ OUX (zwanego też Coux) zaimplementowanego na gruncie C (‹zadanie›, ‹obiekt›, znacznik stanu sygnalizującego kolekcję, ‹raport›), więc jest ściśle związana z projektem przez źródło skrótu, a ma też odrębny związek z obecnymi słowami cząstkowymi fonetycznie lub przez skrót skrótów, ale ta nazwa nie jest już nazwą wewnętrzną projektu, lecz staje się nazwą własną grupy projektów programowanych w definicji OUX lub nazwą handlową, czyli innymi słowy – nazwa ta w oparciu o projekt OUX przechodzi do przestrzeni zarządzanej produktów gospodarczych z woli wykonawczej jej użycia przez osoby odpowiedzialne odpowiednio za promowanie i prowadzenie sprzedaży produktu, określanie polityki dystrybucji.
Projekt OUX został sformalizowany w jego rodzajach implementacyjno‐funkcjonalnych: • system OUX, • podsystem oux oraz • aplikacja OUX. wszystkie one mają grunt tego samego języka, a z punktu widzenia programisty różnią się tylko obecnością złącza sprzętowego bezpośredniego lub pośredniego, które realizuje te same funkcje udostępnianego do użycia ·przepływu wykonania· sprzętu, a nie żadne typy danych i inne konstrukcje granic obrazowych; jakoże i tak w trwałości kreacji Coux programista używa z uwzględnieniem stanu przepełnienia (najlepiej zawijanego) zmiennej — typu “N”, który nie ma górnej granicy rozmiaru. Aplikacja OUX w zasadzie jest tylko miniaturowym podsystemem OUX, ponieważ i tak zawiera moduły podsystemowe, które są częścią jej samodzielnego przepływu wykonania w realizacji niezależnej interpretacji użytkowej (czyli jest programem ‘exokernelowym’ kompilowalnym pod dowolnym rodzajem ‘kernela’ bez konieczności odrębności dyskowej ‹modułów› pomiędzy programami; jak zostanie w przyszłości zgodnie z definicją dawno utworzoną zaimplementowana instalacja ‹modułów› w pamięci dyskowej i operacyjnej). Uzupełnienia do całości teoretycznej OUXPonadto pozostała jeszcze implementacja użycia obiektów przez symbole w programie, z zarządzaniem ich „wyrzucania”, automatycznego zwalniania pamięci.:
- 1⁃ Implementacja ‹zdarzeń› okazała się być już obecną implementacją próbną ‹raportów›, która została odrzucona ze względu na niezgodność z projektem, lecz w tej implementacji nie było ani obsługi ‹zdarzeń›, ani właściwego obiektu odwoływania się w wywołaniu, a tylko czysta implementacja wewnętrznego przepływu wykonania i nie sprawdzona w całości przygotowywanego przepływu wykonania, ponieważ jej użycie nie dotrwało do punktu sprawdzania w ogólnej procedurze wytwarzania oprogramowania. Więc teraz i tak ta implementacja (obecna w ‹module› ‟sterownika przepływu wykonania”) nie musi być uaktualniana, ale może być napisana od nowa właściwie, ponieważ wiadomo, jakie tam zostały użyte konstrukcje przełączające bez dokończenia.
- 2⁃ Problem projektowy pierwszej implementacji OUX polegający na niemożliwości w środowisku obecnych systemów operacyjnych porzucenia ‟ouxy” czyli implementacji zaburzonej o obecność raportu czasu, który wyrażał się w konieczności dokonywania częstotliwościowego próbkowania obecności w kolejce odebranych przez “libx” nowego ‛zdarzenia podsystemu graficznego/okienkowego X’ (‘polling’ zamiast ‘event‐driven’; mimo oryginalnej nazwy “XEvent”, właściwej tylko, gdy stosuje się pętlę główną przepływu wykonania programu do przetwarzania “zdarzeń X” na blokowaniu w “libx”) — został rozwiązany ogólną konstrukcją dla dowolnych systemów operacyjnych (jak powyżej – też nie została jeszcze zaimplementowana), która eliminuje konieczność implementacji OUX jako ‟ouxy”, ponieważ “zdarzenia X” stają się ‹raportami› bez kosztu częstotliwościowego próbkowania.
Język programowania Coux będzie potrzebował własnego kompilatora, który nie będzie zawierał wbudowanych optymalizacji maszynowych, które zaprzeczałyby definicji języka (przez zbędne poszukiwania wzorców optymalizacji naruszające odrębność bytów w tekście źródłowym), a które są obecne w ‟gcc” i podobnie – innych kompilatorach kompilujących C/C++ bez atomowego przepływu wykonania. Ten kompilator być może zostanie utworzony jako implementacja przy podstawowym kompilatorze składni formatów danych, składni niedodefiniowanej o definicjach lewostronnych funkcyjnych; wstępny projekt sprzed lat. Oraz będą powstawać wzorce optymalne konstrukcji wykonawczych do realizacji określonych funkcji w systemie (w ‹menedżerach› i ‹sterownikach›, które przecież są używane otwarcie, jawnie w programach, ściśle integrowane funkcjonalnie w programie).