TYPO3 Core

I'd say you can't add JS resources in USER_INT at all, as they are rendered after the complete page (except some markers for the USER_INT contents) has been rendered.

So I tend to set this to "Rejected", as it's not consistent with the concept of USER_INTs.

If remember the code right, a userint actually can generate three markers in the output stream (function INTincScript()) :
1) one in the headerpart, where js- and css-files/code can be added <!--HD_'.$this->config['INTincScript_ext']['divKey'] + INTincScript_loadJSCode();
2) the marker in the body <!--TDS_'.$this->config['INTincScript_ext']['divKey']....
3) the main marker <!--INT_SCRIPT.

So a fourth marker would be possible. But non-cached javascript should only be usedfor dynamic data as well, the non-changing code can and should be included as normal cached content for performance reason. So wether a third marker really is necessary can be discussed.

I think without this marker, the possibility to move JS from header to footer (config.moveJsFromHeaderToFooter) does not make much sense.
In most cases there are JavaScript-frameworks used, like Prototype or jQuery. If the framework has moved to the footer the methods of the framework (like selectors) could not be used anymore in inline JS.
With an additional marker I can put all my JS-code at the bottom of the page, which is recommended JS usage.
Without the marker the only possibility is to keep all JS in header (which slows down page loading) or use something like the scriptmerger extension to clean up JS files and put them at the bottom.

Well, for normal cached javascript, there is no problem here. And I my opinion a user_int plugin should only it's changing daat assigned to some var as non-cached javascript. Then, the tiny amount of JS used should not hurt. If larger amounts of data are needed, eID+ json are better anyway. But I would not object a fourth marker if somebody creates a patch.

I consider this as a bug, the TSFE->additionalFooterData has been introduced with 4.3 however only for the t3lib_pageRenderer - so we have something like that already.

The problem with USER_INTs is, that e.g. if jQuery was told to be loaded in the footer, you don't have any chance to make use of jQuery in a USER_INT script (e.g. for widgets or something like that). Thus, using the available additionalFooterData seems to be okay - however a lot of stuff is missing there:

$ git blame typo3/sysext/cms/tslib/class.tslib_pagegen.php | grep additionalFooterData
6bea4ac3 (Steffen Kamper     2009-09-06 21:32:48 +0000 1028)         if ($GLOBALS['TSFE']->additionalFooterData) {
30c60eef (Benni Mack         2010-04-12 16:17:20 +0000 1029)             $pageRenderer->addFooterData(implode(LF, $GLOBALS['TSFE']->additionalFooterData));

Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/11860

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/11859

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/11859

Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/11859

Patch set 5 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/11859

Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/12571

Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/13289