Missing project page and README.txt documentation.

Not the case.

multipage and multipage group does not work on user entity, even after adding the container. that is the main bug report.
adding multipage group (container) and multipage (item within the group) does nothing. all fields remain on user/%/edit page as if no multipage/group settings were defined.

#1409340 was just a minor annoyance (although made no difference in final outcome).

I hope this writeup saves some time for others with similar goal.

User entity will require very special handling to enable splitting fielded user entity form into multipage display (ie, multi-step form) because of the following reasons:

1) user.module provides functionality to split user/%/edit form into various "category page"s. Modules implementing hook_user_categories can add new second level tabs to appear on user/%/edit page. So multi-step/multipage user form functionality is supported "out of the box" by core.

2) user.module implements default 'account' category (ie, if you go to /user/%/edit or /user/%/edit/account you will get the same page/form). During this default (category == 'account') behavior, user.module adds various default user account form fields, as well as attaches fieldAPI fields (field_attach_form...).

3) When you attempt to view any category other than 'account' user.module skips adding default fields (as well as fieldapi fields), and this is where things begin to "break" (still work, but not as wanted/expected). So for example if you move some fields under category "profile", and visit /user/%/edit/profile you will end up with entirely empty page. this is because user.module assumes that modules implementing hook_user_categories will handle user entity form in an entirely custom way so it skips adding fieldapi fields (fields that are added on admin/config/people/accounts/fields page).

@swentel: I haven't had the chance to read through field_group code to see exactly how it works, so i hope my question doesn't come off too shallow.

Are you suggesting that multipage and multipage group field_group settings work using /javascript/ only? My past experience writing multi-step forms lead me to assume that when manipulating fields into multipage group you would end up with form structure which when rendered will yield only the desired fields for given step and nothing more.

ie. setting undesired fields to $form['field_1']['#access'] = FALSE; etc etc.

if i understand your example correctly, multipage and multipage group field_group settings will render entire form and then hide various field groups using javascript (effectively emulating behavior of jquery ui tabs) ???

Ah!. that is good to know.

This is a very important implementation detail. in fact it is of critical importance. Would it be possible to add a note on project page and in README that this module provides front-end-only handling?

Original bug that i filed assumes this is all handled on server end. So this issue should be set to "closed (works as designed)" since when i enable js it begins to work again.

Leaving issue as 'active' for now so it sits at top of issue queue nagging hopefully to add the very important note to project page that this module provides only front-end solution.

cheers.

Changing issue title to reflect better.
summary:
1) project page and readme.txt need documentation that this module provides front-end only functionality.