TYPO3 Core

I think this is no bug. The type can be included in the typolink.parameter property. Then simulateStatic should work correct - realurl does.
For your TS:

page.10 = TEXT
page.10 {
stdWrap = 1
stdWrap.typolink {
returnLast = url
useCacheHash = 1
parameter {
data = tsfe:id
wrap = |,5
}
}
}

That's correct. But you're wrapping the parameter to set the type. My approach is setting - the type. So you're making a step around to do what could be done directly. Look at this as kind of HCI issue.

The parameter "type" has a special meaning in TYPO3 and so it's handled special. It should always be set according to TSRef [1] else there are some other side effects, too.

[1] http://typo3.org/documentation/document-library/references/doc_core_tsref/4.0.0/view/5/8/

as you can see in class.tslib_content.php in function typolink, the type get's his special part in $link_param, which takes data only from parameter:

unset($theTypeP);
$pairParts = t3lib_div::trimExplode(',',$link_param);
if (count($pairParts)>1) {
$link_param = $pairParts⁰;
$theTypeP = $pairParts¹; // Overruling 'type'
}

So in my opinion this has to added by a special parameter, like this:

10.typolink.parameter = 7
10.typolink.type=150

with adding one line after above mentioned code:
if($conf['type']) $theTypeP =$conf['type'];

something like this would be my suggestion. I've tested and for me works perfect.

and then there is an easy way to overrule the type fom TS or php.

parameter.dataWrap = {TSFE:id},5

Hi guys!

You must be kidding ;)

"Now the input can be an alias or page-id. If the input is an integer it's a page-id, if it's two comma separated integers, it's a id/type pair, else it's an alias."

This is the only passage in the TSRef which shows how to handle the type parameter. I don't consider myself a good php programmer, but I do have some knowledge about "well written code" and this is definitely something underneath loooooow level. How can you combine a parameter with another one like that if you can use multiple parameters for a function call?
Why is function($address), where $address is a csv-list, dieing out? Because today you can write it better and more user-friendly: function($name, $street, $zip, $city).

So please, consider a change of code. I know that this is not a bug, but something that could make life a lot easier.

I vote for Steffen Kamper's solution:

10.typolink.parameter = 7
10.typolink.type=150

@Thorsten Kahler Kahler

Where do you find something about side effects in TSRef [1] if the type is not set? Has it been removed from that page. For me the type still defaults to 1 of not set.

[1] http://typo3.org/documentation/document-library/references/doc_core_tsref/4.0.0/view/5/8/

Well, while solution already exists (see my example with dataWrap), but I lik Steffen's solution too. Except that it has to be a proper patch to get into core (unified diff).

ok, i uploaded the patch as diff.

The change is very small
unset($theTypeP);
was changed to
$theTypeP =$conf['type'];

Now the old way works as well, but type can be given with conf.
Example:

10 = TEXT
10.value = Standard Link
10.typolink.parameter=3,150

20 = TEXT
20.value = New Link
20.typolink.parameter = 3
20.typolink.type=150

Please check it out.

To make the matter complete we should also think of the other values of parameter. At least the "class" attribute could be available as dedicated typolink property. The id attribute is also a candidate.

I don't want to hider the processing of this patch, so I made it an own feature request: http://bugs.typo3.org/view.php?id=6062

The other thingy is the JS popup. But that is more complex and less interesting.