I think I understand your response; but I just want to clarify that KM can identify the same window(s) to successfully move, resize, minimize, etc., based on position (front) or title; so it still seems very odd to me that KM fails to identify that same window in the same macro one action later if finding an image within said window is the action.
And I, out of habit with automation quirks, rarely use exact title parameters, if it's not absolutely necessary; I always use 'contains' or 'begins with'; so, in my case, the window I'm after always begins or at least contains 'Google Hangouts', but indeed changes based on whatever account might be logged in; thus my macro is portable to other users.
KM first looks for that window, and brings it to front; if it's not there, it uses a subroutine/macro to open; it then moves it and sizes it to a specific location, then it either conditionally begins or takes a phone call, based on image conditions. So KM has no problem finding the window by name and position in the first place, but borks on images using identical identifiers. I'm not exactly certain how the CG/Accessibility explanation fits this scenario, given you are using title as example, but I'll trust you that it's Google's fault, since it worked prior to Chrome 69.xxx; hopefully whatever they broke will get fixed, else I hope other users getting nailed by this and spending far too much time troubleshooting the completely baffling problem and useless error messages (given the above stated success with other actions) find this thread.
I'm super grateful for @ccstone 's solution/workaround to the problem, which is a feature of that action I've never explored or needed before. I try to avoid image-based actions whenever possible, even if more work is required, but that may ultimately be both faster and more reliable due to changes in artwork.
Love this forum; love the heroes in it. Cheers. -- F