XQuery is a functional query language for XML in which generally no order for the evaluation of sub-expressions is assumed. However, there are in fact several sources of side effects, including a subtle one caused by element constructing in the current version, data manipulation outside of the language by user-code via API, and possible future update extensions. They prevent an implementation from optimization by reordering the execution or parallel processing. In this paper, two approaches are proposed to tackle these obstacles. One is to reconsider the treatment of the store, and the other is to introduce a way to identify the portions where the updates actually take place. We believe these propositions will help the implementations perform safer optimizations.