This should be check on Ubuntu. On Windows it can not be reproduced.
You may blame the J!Tracker Application for transmitting this comment.

I recreated this bug on OS X Mavericks ans Safari 7.
You may blame the J!Tracker Application for transmitting this comment.

@test
cannot reproduce on Chrome with Mac
(fresh installed Joomla 3.3. staging)

@test
Cannot reproduce on Google Chrome 35 on Ubuntu 12.04. Config values are displayed correctly after save.
What's the "cache" configuration to reproduce the error?

@test
cannot reproduce on Firefox on a Mac

@test
I can not reproduce the error at Chromium Version 34.0.1847 (Debian 7.5)
You may blame the J!Tracker Application for transmitting this comment.

I can confirm the issue on Ubuntu 14.04 + Firefox v29.0

Changes are saved but not shown properly if you don't reload the page.

You may blame the J!Tracker Application for transmitting this comment.

This fixes the issue: #3701

Video with the demo of the issue:
https://www.youtube.com/watch?v=4l20bNORxw8&feature=youtu.be

What are your cache settings? It could be related to
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32984&start=0

My cache is OFF. You had the problem in Safari so I think that discards a linux or firefox problem. Seeing the patch you can see that is obvious that the form data is not saved in the session except if the form has an error.

Imho, we usually don't save the data into the session on success. It's not needed because in that case the data should be reloaded from the file/database.

We need to store the data into the session on failure so we don't loose the changed data the user changed.

So imho the current code there should actually be correct. But I have no clue why it fails in your cases.

I can confirm the issue on mac OS X 10.6.8 + Firefox v30.0 + Joomla 3.3.1

Patch #3701 from Roberto is fixing this issue! Well done!

@Bakual I would also prefer to force a fresh reload each time but it doesn't work even forcing the session com_config.config.global.data destruction to be sure nothing is pre-loaded from session. The config loaded is the previous to the save even after a page redirection on save (of course with cache disabled).

I have also spent hours playing with php.ini settings to see if there is a server setting that can cause that issue and checking if it could be related to the BOM fix applied to avoid configuration errors.

The only thing I know is that the issue exists and that storing the session data does not cause any issue. So applying JM's philosophy on this: "if somebody finds a better fix for this in the future apply it. Meanwhile fix it".

interesting bug ;)