If you force the position of course it will use the same position. That's what is a "force" - everything else is a bug.

Your wished behavior should be able to achieve by using a kwin script.

i'll mark this as invalid since as martin stated "force" means "force" and by this overrides any normal placing strategy.
"Maybe force" is too specific for the particular case and thus needs scripting.

Former position storage is actually matter of the client.
I don't think KDE applications do this (and why should they? Chances are good that former position makes no sense now)

Afair the default placing strategy is "smart" what prevents occlusions as long as the client does not request a specific position.

So questions:
- which client in particular?
- why do you force to remember the position in the first place? (there's the actual issue and it can maybe solve another way)

Regardless of the question a possible solution might be to "sharpen" the rule (invoke window title to only catch the first xterm or whatever)

Thanks for pointing me towards kwin scripting. ECMAScript is above my head though.

It's of course just my personal opinion but I think having the kind of window management I described is desirable enough to warrant at least an additional GUI option in the advanced window settings. It's what I'm used to from OS X and Windows and I prefer it to the default smart placement and other available options.

I can manage to emulate most by setting up "sharper" rules as you said, for each and every window I regularly use, but it would be nice to have a rule that automatically remembers ALL window positions and cascades further windows. I don't have particular clients in mind. I'm really thinking of a replacement for the smart, centered, zeroed corner, tiled... mode by adding a new "Windows/OS X WM" emulation mode.

> I'm really thinking of a replacement for the smart, centered, zeroed corner, tiled... mode by > adding a new "Windows/OS X WM" emulation mode.

-> you'd have to make a wish for kdelibs, qt, gtk+, motif, tcl/tk, java, [...place other toolkits here] then - or have a rule for every window anyway; How'd you remember positions for separate clients otherwise? A "blind" rule (matching all windows) won't work, since they'd all remember the very sam (last) position.

A kwin placement strategy (NOT override rule - that's no fun to build yourself ;-) won't work, since it would rapidly grow an enormous list (you'd /have/ to invoke the title) to query everytime a client shows up.

>Former position storage is actually matter of the client.

>A kwin placement strategy won't work, since it would rapidly 
>grow an enormous list...

It's clear that if we want to remember the positions of all windows they need to be stored somewhere, parsed and probably purged from time to time. If it's client side it's likely faster and more manageable but does a WM side list have to be slow and unmanageable?

I only know of one unwieldy window properties list, the Windows Explorer which stored size and position in the registry. It's a client but the file manager probably has more individual windows, if you try to remember them per folder, than any other client.
They got rid of it (in Windows 7 the Explorer only remembers one position and size for all windows) but as fas as I know the only reason it failed was because the default maximum size of the "Bags" as it's called was too low for many people. Maybe the maximum size was because of performance reasons but that's the Registry we are talking about :P

I've tried the KDE Windows "Initiative" and not very surprisingly the Windows WM doesn't handle the cascading of second windows as with native toolkit windows. All windows of the same KDE application get put on top of each other as if KWin was used with the force/remember position. Gtk apps like Gedit for Windows just get put randomly btw. Getting all toolkits on the same page is a futile idea so I've come up with a compromise which might not only be better technically but also in terms of UX:

Add a new cascade placement option that doesn't start in the top left corner but, if there's already a window of a particular application open (and focused?) cascades additional windows below window #1. This should be changeable on a per application basis.

This way I can easily emulate and improve on the OS X/Windows behavior by setting up a remember position rule for all first windows of applications I use frequently and where it makes sense and let KWin manage the rest by the cascade rule or the default smart placement depending on what application I'm using.

I hope this is possible to do with KWin. Sorry about changing the scope of the bug with every post I make :(

> Add a new cascade placement option that doesn't start in the top left corner
> but, if there's already a window of a particular application open (and
> focused?) cascades additional windows below window #1.
That's technically no problem, but would be trumped by your window rule (the rule strategies would have to be extended by "remember if i'm the first"

> This should be changeable on a per application basis.
Not possible. KWin manages windows, not applications. The relation is weak and not portable (tracing the optional NETWM PID property - resolving the commandline from the PID is rather not portable, even not amonx *nix systems)
Also defining window placement in relation to a client class list sounds a bit like overhead (and like a second layer rule system)

The driving question though remains: "Why"?

I mean, the amount of clients that would usually fall under this condition anyway is relatively small (two dolphin instances, maybe two konsoles - did you know that you can split dolphin?) and then it's still hard to understand why you'd want to remember the position (and esp.) of such rather generic windows (i do see the point in forcing a position for eg. oclock, but just showing up where closed last time? Maybe interfering with other windows currently on the desktop?)

"Windows does it" doesn't count ;-)
So what do you think would be the benefit of a position re/storing system - is it maybe related to one particular client (ie. "application")?

>That's technically no problem, but would be trumped by your window rule (the
>rule strategies would have to be extended by "remember if i'm the first"
I'd just set up rule for window role: "application_name #1"
The window with the role "#2" is not affected by that and gets placed according to whatever placement mode you have chosen.

>Not possible. KWin manages windows, not applications.
I'm referring to Advanced -> Special Application Settings... -> Geometry -> Placement. There I'd like to have a new option saying: Cascade below parent window. 

>The driving question though remains: "Why"?
Thanks for keeping asking the right questions! 
On a high level the idea is to group windows of the same application together. The smart placement is very wasteful with screen estate. After just a couple of windows everything is covered. It's not "smart" enough to consider I might open yet another batch of windows and be a little more conservative and organized.

On a large monitor I always set up the file manager in one corner, the editor in another, the terminal on a side and the writer and browser in the center. Everything is organized and predictable. When I open a new window (ctrl+n) I want to have that window open near to the "parent" window - without completely obscuring it.

I just realized KDE got a solution for that already, the group similar window features. It's almost perfect for my workflow. Just one little annoyance: when I detach a window the grouping is completely stopped and all new windows will be placed freely. I'd prefer having them grouped in the new window or the old group. 

Thanks for your time and patience!

*** This bug has been marked as a duplicate of bug 58063 ***