In Google Wave, there were four types of reply threads:

inline=false, no content anchor => an indented reply thread outside the parent blip. inline=false, with content anchor => corrupt data, but treated anyway as above inline=true, no content anchor => unanchored inline reply, rendered at the end of the parent blip (inside). inline=true, with content anchor => anchored inline reply, rendered at the content anchor (inside).

In Undercurrent / WIAB, this distinction based on the inline attribute in the manifest is no longer made. Reply threads are just reply threads. Any reply thread can have an anchor in its parent blip's content, and if there is such an anchor, the thread is rendered there, otherwise it is rendered at the end of the parent blip's content. The rendering and behaviour of the two cases is identical (unlike Google Wave). The only difference is the location where the thread is rendered. Essentially, this means that "indented" replies, as opposed to "inline" replies, are gone.

All code that is causing divergent behaviour based on ConversationThread.isInline() needs to be fixed. In most cases, the expression: ConversationThread.isInline() can be replaced with: true followed by consequent refactoring and dead-code removal etc.