positioning oddity, *TOP and *BOT; WRKF, WRKDTAARA, WRKOBJ, ¿others?

I am shocked that I only just now noticed this bizarre effect: If I use a F17=Position-to request and use either of the special values *TOP or *BOT within a job, the next Work With panel *might* position with the /previous/ positioning preference; apparently any WRKxxx feature that /shares/ the same Interactive Profile Entry (IPE) position-to data.

I tried to find some past discussion topic(s), but located none. The release where I tested was very old. Perhaps someone can confirm the effects in a current[ly supported] release.? If confirmed, is the effect not clearly a defect, or what possible value is there in the effect [across disparate WRKxxx requests]?

The result upon visiting the next Work With menu panel [after using F17=Position-to in a prior WRKxxx request] is acting as though I had pressed the F16=Repeat-position-to in the newer WRKxxx request, but failing to have logged an informational msg CPC2366 "Positioned to bottom of list" or msg CPC2365 "Positioned to top of list". Restated, the effect is as though the current WRKxxx is remembering the *PRV [previous] positioning value specified on a F17=Position-to from the prior WRKxxx processing, and that *PRV value is implicitly reflected in the current Work With list. Yet upon visiting a new invocation of a WRKxxx, the interface will kindly inform the requester of a F16=Repeat-position-to that, per msg CPD2367, "No position to performed previously". So which is it? Did I really have no previous position such that perhaps the default for a new invocation should always be to *TOP, or did I have a previous position [stashed away in the IPE] that was properly reflected in my current positioning within this new WRKxxx request?

Some more thoughts\comments...

Interesting side note, the [v5r3] help-text for the "Position the List" pop-up, mentions nothing about those special values *TOP and *BOT even being supported :-(

The behavior is quite unexpected given the positioning support in one panel might be totally incompatible with another; e.g. one panel might present a list for which object-type [i.e. WRKOBJ] might be included in positioning, whereas another may support only the object name, and others might need to support name and library. Also quite unexpected, given *only* the effects of those two special values are ever reflected in the next visit. Of course, I hardly want my request to position to the bottom of my Work With Files to have *any impact* on my later request to Work With Data Areas; they are of course, totally unrelated requests, for which my positioning requests should be maintained distinctly.

I can not imagine the behavior was designed as such, and instead imagine that the effects must be unexpected; a side-effect of the shared IPE data, and an unintended consequence, aka defect.? At least if the behavior was designed, then the position-to a starting character should exhibit the same behavior; i.e. the /next/ visit to an unrelated Work With panel should position me to the same starts-with.? Why would the latent effects of positioning, from a prior WRKxxx, be seen only with prior use of *TOP and *BOT rather than seen with all possible prior positioning requests? But why anyone would want either a *BOT or a starts-with-J positioning request to be an implicit effect on an upcoming WRKDTAARA request after some past WRKF request had requested such positioning. from perhaps many hours prior, I can not fathom; either seems just as daft.

FWiW: I noticed the effect when I was reviewing the list from a WRKF QTEMP/*ALL request. Seeing only one file [although I expected more files should have been listed there], I deleted that one file. Suddenly, another file appeared in the list! I eventually determined that I [must have] utilized *BOT positioning in a prior WRKxxx menu sometime prior in my job; though unknown, easily inferred from results testing in a new session that had not been exhibiting the effect until after I used the *BOT in F17=Position-to.